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1 MULTI-PROTOCOL WIRKLESS COMMUNICATION 

2 APPARATUS AND METHOD 

3 Field Of Thf Invention 

4 The invention is directed to a wireless communications apparatus and method. 

5 In particular, the invention is directed to a multi-protocol, scaleable wireless switching 

6 platform and method. 

7 Background 

8 Wireless communications in the United States were initially conducted solely 

9 through analog systems and protocols. The most prevalent analog protocol remains 

10 the Advanced Mobile Telephone System (AMPS) protocol. To handle wireless 

1 1 communications and to allow interconnection with traditional wired land-lines, 

12 switchingsystems and base stations were required. The analog switching systems are 

13 large and are designed to cover large markets and handle large volumes of calls. 

14 ^ I990*s digital systems and protocols began to be used for wireless 

15 communications. Examples of digital protocols are the Global System for Mobile 

16 Communication (GSM) code division multiple access (CDMA), and time division 

17 multiple access (TDMA). When wireless networks began to switch to digital 

18 protocols, they could not simply upgrade their analog base stations to digital. New 

19 equipment for the digital facilities was required. However, the networks continued to 

20 use large switching systems designed to cover their large spread markets. Examples 

21 of large switching systems are AT&T's 5ESS® system and the AXE system made by 

22 Ericsson. The 5ESS® switch is described in detail in the AT&T Technical Journal, 

23 Vol. 64, No. 6, part 2, July/August 1985, pages 1305-1564. 

24 Large switching systems are designed to cover large markets and to handle 

25 many thousands of customers. The larger systems have the advantage of being able to 

26 provide a wide range of call options, such as call forwarding, caller identification and 

27 call waiting. The switching systems are expensive, however and, therefore, may not 

28 be appropriate for small markets and wireless providers. AdditionaUy, large switching 

29 systems can be inefficient because of the added additional cost for increased back 

30 hauls of calls. 
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Typical switching systems employ proprietary architectures that use hardware 
components for switching, external interfaces, operating system, and control. 
Summary Of The Invention 

A multi-protocol mobile switching center (MSC) provides wireless 
communications for mobile devices operating on a local wireless network according 
to any standard protocol including those of the Global Systems for Mobile 
Communications (GSM) standards and IS-41 standards (including time division 
multiple access (TDMA), code division multiple access (CDMA), and Advanced 
Mobile Telephone System (AMPS)). The MSC may be incorporated onto a single 
platform having a home location register (HLR) and an authentication center (AC or 
AuC), as well as a visitor location register (VLR) and an equipment identity register 
(EIR). 

The multi-protocol MSC is scalable so that it may be used for a small number 
of customers, such as in a rural setting to provide telephone access, or as part of an in- 
building communications network. The scalable, multi-protocol MSC may also be 
used to construct a large, distributed wireless network. Thus, the scalable, multi- 
protocol MSC provides the flexibility to be used with a wide range of customer bases, 
and within a variety of different typographies. 

Because the MSC can process wired and wireless calls according to any 
protocol, a single switching center may serve customers who operate mobile and fixed 
communications devices, regardless of protocol. This true multi-protocol 
functionality makes this switching solution extremely efficient and cost effective, and 
eliminates the need for separate, protocol-specific components. 

The multi-protocol MSC can be housed in a standard chassis. The multi- 
protocol MSC can use standard, off the shelf hardware for most data storage and 
processing functions. The multi-protocol MSC can be easily updated to take 
advantage of industry advances by simply replacing select components in the chassis. 

The multi-protocol MSC provides full-featured telephone and data services, 
including wired and wireless analog and digital telephony, conference caHing, prepaid 
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1 calling, emergency call routing and long-distance resale. The multi-protocol MSC 

2 also provides pocket switching applications such as asynchronous transfer mode 

3 (ATM). 

4 The multi-protocol MSC incorporates advanced graphical user interfaces 

5 (GUIs) that display system data in a convenient, easy to access format. A system 

6 operator can quickly select data for display, and can easily modify selected data 

7 entries. The system operator can control operation of the multi-protocol MSC using 

8 the intuitively structured GUIs. 

9 The multi-protocol MSC may incorporate a number of sophisticated features 

10 in addition to the HLR, VLR, EIR and the authentication center. These features 

11 include an operations and maintenance center, wire line and tandeming services, and 

12 hot (real-time) billing and prepaid services. 

13 When used for distributed switching, the multi-protocol MSC may reduce 

14 build out and operational costs associated with large switching centers. This 

15 architecture also elirninates needless back hauling by switching local calls locally. 

16 Finally, the architecture allows for add on as a wireless customer base expands. 

17 The multi-protocol MSC includes a first interface that receives digital and 

18 analog communication according to a first protocol and a second interface that 

19 receives digital communication according to a second protocol. The first and the 

20 second interfaces include inter system (system-to-system) message handlers and 

21 intra system (within system) message handlers. 

22 The hardware and software architecture of the MSC is designed to use generic 

23 signaling as much as possible to provide call connection and other functions. 

24 Protocol-specific communications are handled at a device handler (lower) level, and 

25 higher level processing uses generic messaging. A table may be used to map 

26 messages of the different protocols to the generic messages used by the MSC. The 

27 hardware of the aircore system is based on off-the-shelf industry standard components 

28 for each of the four areas typically found as proprietary in current systems. The use of 
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off-the-shelf standardized switching components, interface boards, operating system 
and control processing provide a unique evolution path for the aircore system. 

The HLR and VLR are structured so that data that does not depend on a 
specific protocol is stored in a common memory portion while protocol-specific data 
is stored in protocol specific portions of the HLR and VLR. This logical arrangement 
of the HLR and VLR provides for quick access to data by components of the MSC 
and allows for easier updating by a system operator. 

An advanced intelligent message (AIM) handler interfaces with the VLR and 
the HLR to determine the current location and identification of mobile units homed on 
the HLR or roaming in the local wireless network. The AIM also determines the 
protocol applicable for the mobile unit. For calls received at the MSC from a local 
.wireless network base station, the protocol determination may be made by reference to 
the protocol of the base station. For multi-protocol base stations, the determination 
includes decoding information provided in the service request or similar message sent 
by the base station. For other mobile units, the MSC may communicate with external 
wireless components such as other HLRs, VLRs, and MSCs. 

The MSC includes an authentication and registration system that controls 
registration of mobile communications devices operating on the system controlled by 
the MSC, The authentication and registration system also provides encryption and 
ciphering of voice and data communications. 

The MSC can also be used as an adjunct to a private branch exchange (PBX) 
to create an in-building wireless network. Used as such, the MSC and HLR can be 
used to route calls preferentially among mobile units and fixed telephones and other 
communications devices. 
Brief Description Of The Drawings 

The invention will be described in conjunction with the following figures, in 
which like numbers refer to like features, and wherein 

Figures la - Id show wireless communication environments according to the 
invention. 
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1 Figure 2 is a block diagram of an aircore switching platform. 

2 Figure 3 shows a wireless loop architecture. 

3 Figure 4 shows a fixed wireless loop architecture. 

4 Figure 5 shows the aircore platform with local area mobility. 

5 Figure 6 shows the aircore platform with system level mobility. 

6 Figure 7 shows the aircore platform with full scale mobility. 

7 Figure 8 shows a wireless network architecture. 

8 Figure 9 is a block diagram of aircore functions. 

9 Figures 10 is a block diagram of the aircore software architecture. 

10 Figure 1 1 is a block diagram of the advanced intelligent message handler 

11 architecture. 

12 Figure 12 is a block diagram of the A-interface message handler. 

13 Flgure 13 is a block diagram of the ISDN user part message handler. 

14 Figure 14 is a block diagram of a intersystem message handler. 

15 Figure 15 is a block diagram of a device handler for voice input-output 

16 devices. 

17 Figure 16 is a block diagram of a device handler for digital interfaces. 

18 Figure 17 is a block diagram of a device handler for ISDN interfaces. 

19 Figure 18 is a block diagram of a device handler for signaling system 7 

20 communication. 

21 Figure 19 is a block diagram showing software interlayer communications. 

22 Figure 20 is a logical representation of the home location register. 

23 Figure 21 illustrates the HLR/VLR database structures. 

24 Figure 22 is a block diagram illustrating the location management feature of 

25 the visitor location register. 

26 Figure 23 is a state machine for mobile originated call processing. 

27 Figure 24 is a state machine for PSTN originated call processing. 

28 Figure 25 is a state machine for mobile terminated call processing. 

29 Figure 26 is a diagram of a near end facility state machine. 
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1 Figures 27 is a diagram of a far end facility state machine. 

2 Figure 28 is a diagram illustrating mobile unit hand off. 

3 Figure 29a shows the software components used for call processing. 

4 Figure 29b shows the object structure for the aircore call processing. 

5 Figure 29c is a flow chart illustrating an authentication process. 

6 Figures 30-34 are flow charts showing message signaling associated with 

7 interface maintenance. 

8 Figures 35-40 are flow charts showing message signaling associated with trunk 

9 management. 

10 Figures 41-47 are flow charts showing message signaling associated with 

1 1 mobility management. 

12 Figures 48-66 are flow charts showing message signaling for call processing. 

13 Figures 67-71 are flow charts showing message signaling associated with call 

14 processing with an external HLR. 

15 Figures 72 is a flow chart showing message signaling associated with hand off 

1 6 pre-processing. 

17 Figure 73 is a logical diagram of a prepaid rating system. 

18 Figure 74 is a flow diagram illustrating emergency call processing. 

19 Figure 75 is a block diagram illustrating first party call control. 

20 Figure 76 is a block diagram illustrating third party call control. 

21 Figures 77-79 are block diagrams of call delivery methods using third party 

22 call control. 

23 Figure 80 is a block diagram of an in-building wireless communications 

24 network. 

25 - - Figures 8 1 -84 are block diagrams of an embodiment of the aircore platform 

26 hardware architecture. 

27 Figures 85-86 are block diagrams of another embodiment of the aircore 

28 platform hardware architecture. 
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1 Figures 87- 123 illustrate graphic user interface screens for use with the aircore 

2 platform. 

3 Detailed De scri ption Q f The Invention 

4 Mobile telecommunications (radio) systems that permit customer calling from 

5 mobile stations such as automobiles, or small light weight hand held personal 

6 communications units are becoming increasingly prevalent. These systems use the 

7 principles of cellular technology to allow the same frequencies of a common 

8 allocating radio bandwidth to be reused in separated local areas or cells of a broader 

9 region. Each cell is served by a base transceiver station comprising a group of local 

10 transceivers connected to a common antenna. Base station systems, each including a 

1 1 controller and one or more transceiver stations, are interconnected via a switching 

12 system, called a mobile switching center (MSC), which is also connected to the public 

13 switched telephone network (PSTN), and the Public Land Mobile Telephone Network 

14 (PLMN). These mobile telecommunications systems are now entering a second 

15 generation characterized by digital radio communications with a different set of 

16 standards, such as the European Global System for Mobile Communications (GSM) 

17 standard promulgated by the Special Mobile Group (SMG). The GSM standard is 

18 also being adapted for use in the United States. In addition, in the United States, 

19 CDMA, TDMA, DAMPS, and AMPS are used for digital cellular mobile 

20 communications. 

21 The mobile telecommunications systems have many components that need to 

22 communicate signaling information for controlling the establishment of connections. 

23 Such signaling information is communicated over channels that are separated from the 

24 channels carrying actual voice or data communications between the connected 

25 . customers. Among the components that need to communicate to establish voice and 

26 data communication links are the mobile units, the base station system connected by 

27 radio to the mobile units, the mobile switching center and the various databases that 

28 are consulted for the establishment of mobile calls. These databases include a home 
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1 location register (HLR) with an authentication center (AC (IS-41) or AuC (GSM)), a 

2 visitor location register (VLR), and an equipment identification register (EIR). 

3 Signaling messages among these components are processed by many 

4 expensive protocol handlers. In the past, these protocol handlers were too expensive 

5 to permit incorporation into a single unit Modem switching systems typically include 

6 expensive MSCs, such as AT&T's 5ESS® switch. These systems only make sense for 

7 deployment when there are a large group of mobile customers who will use the 

8 system. 

9 This invention uses advanced signal processing, a novel method of structuring 

10 signal processing software and an enhanced home location register/visitor location 

1 1 register to provide multi-protocol, scaleable mobile telecommunications capability. 

12 The software architecture is specifically designed so that generic processing is used to 

13 the maximum extent possible to process signals and data related to different digital 

14 and analog protocols including GSM, TDMA, CDMA and AMPS, and proprietary 

15 protocols. 

16 Figure la shows a general arrangement of a mobile telecommunications 

17 environment 100. At the heart of this environment 100 is an aircore platform 200 of 

18 the invention. The aircore platform 200 receives messages from, and transmits 

19 messages to a variety of fixed and mobile sources, conforming to each of the protocols 

20 employed by the sources. 

21 Base transceiver stations (BTSs) 110 receive messages from and transmit 

22 messages to the aircore platform 200 over land lines 1 13. The land lines 1 13 may be 

23 any telecommunications medium that is capable of high speed data transmission, such 

24 as fiber optic cable, T-l and E-l lines and coaxial cable, for example, 

25 The BTS 1 10 transmits messages to and receive messages from mobile and 

26 fixed sources. In Figure la, the BTSs 1 10 are shown in wireless communication with 

27 mobile phones 1 12, a mobile phone in a car 1 16 (a roaming mobile phone), a 

28 microcell 1 15, and a wireless local loop 150. The wireless local loop 150 may include 
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several connections. The wireless local loop 150 is described in more detail below. A 

2 telephone 1 1 8 may operate in conjunction with a private branch exchange (PBX). 

3 The BTSs 1 10 may operate in conjunction with the fixed and mobile sources, 

4 according to one of several wireless protocols as set forth above. 

5 The aircore platform 200 communicates with a public switched telephone 

6 network (PSTN) 120 via a wired path 12 1 and with a wireless network 130 via a 

7 signal path 131. 

8 The aircore platform 200 also communicates with a satellite 141 via a satellite 

9 receiver 140. 

10 Figure lb shows a GSM wireless environment 101. The aircore platform 200 

1 1 connects to the BTS 1 10 via a base station controller (BSC) 105. Mobile units 1 12, 

12 the roaming mobile phone 1 16, the wireless local loop 150 and the microcell 1 15 

13 communicate by way of wireless radio channels with the BTS 1 10. The aircore 
platform 200 also connects to a GSM MAP network 133 via landline 132 and to the 
PSTN 120 via the landline 121. Finally, the aircore platform 200 communicates with 

16 the satellite 141 via the antenna 140. 

17 Figures lc and Id show wireless environments 102 and 103, respectively. The 

18 wireless environment 102 is used with CDMA-protocol mobile units and base 

19 stations, and the wireless environment 103 is used with TDMA-protocol wireless 

20 units and base stations. 

21 Figure 2 shows the aircore platform 200 in more detail. In Figure 2, the 

22 aircore platform 200 includes a mobile switching center (MSC) 210. The MSC 210 is 

23 configured such that the aircore platform 200 can receive and transmit multiprotocol 

24 wireless communications and wired communications with a variety of platforms. The 

25 MSC 210 may include, a visitor location register (VLR). Alternately, the VLR may 

26 be separated from the MSC 210. The aircore platform 200 also includes a home 

27 location register (HLR) 212. The HLR 212 includes permanent information about 

28 customers who use the local environment serviced by the aircore platform 200. The 
data stored in the HLR 212 is the permanent data that is independent of the customer's 
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1 present location, plus temporary data stored such as the address of the system (may be 

2 signaling system 7 (SS-7) or other system) where the mobile unit is currently 

3 registered and the address of service centers that have short messages for a mobile 

4 unit. An example of such a short message is a request to turn on a voice message 

5 waiting lamp indicating that a voice message has been stored for the mobile unit's use 

6 in a voice messaging system. These addresses are erased after the short messages 

7 have been delivered. The signaling system 7 (SS-7) is described in detail in A.R. 

8 Modarressi, et aL, "Signaling System No. 7: A Tutorial," IEEE Communications 

9 Magazine, July 1990, pp. 19-35. 

10 The VLR contains the profile data for the mobile unit and the transient data for 

11 each mobile customer, including the mobile unit's present or most recently known 

12 location area, the mobile unit's on/off status, and security parameters. 

13 An authentication center 2 1 3 is used to ensure that only properly authorized 

14 mobile and wired sources communicate through the aircore platform 200. The 

15 authentication center 213 provides authentication encryption parameters to ensure that 

16 a mobile customer cannot falsely assume the identity of another mobile customer and 

17 provides data for encryption of the voice data, and control signals transmitted via the 

18 air between the mobile unit and the servicing base station system. Encryption is 

19 desirable for the transmission of messages between the mobile unit and the radio 

20 transceiver at a base station serving that mobile unit because it is possible to listen in, 

21 or tap, the radio channels carrying voice communications. 

22 An equipment identity register (EIR) 211 includes a database of the mobile 

23 equipment using the aircore platform 200, including specific protocols and equipment 

24 preferences. The EIR 211 retains the ranges of certified equipment identifications and 

25 the ranges of, or the individual equipment identifications that are under observation or 

26 barred from service. The equipment identification information is received from a 

27 mobile unit at the MSC 2 10. The EIR 21 1 is used to verify that the equipment 

28 number of the mobile unit is certified for use in the public network and is not on the 

29 observation or service barred list. 
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The MSC 210 is connected to other wireless network components and to the 
PSTN for accessing land-based customer stations and to the integrated services digital 
network (ISDN) for communicating according to ISDN protocols. A base station 
system (BSS) 104 may include the BSC 105 and one or more BTSs 1 10 for 
communicating with mobile units. The BSS 104 and the mobile units communicate 
via radio connections. The BSS 104 is also connected via trunks to carry the voice, 
data, and control messages between the mobile units and the MSC 210. The BSC 105 
and the BTS 110 may be in different physical locations (for example, the BSC 105 
may be co-located with the MSC 210 in which case a trunk is required to interconnect 
the two). This is done since the communications between the BTS 1 10 and the BSC 
105 can typically be compressed to optimize the BTS connectivity requirements. 

Figures 3 - 7 show different mobility architectures that can be used with the 
aircore platform 200. In Figure 3, the aircore platform 200 is shown communicating 
with the BTS 1 10. The BTS 1 10 may service the wireless local loop 150. The aircore 
15 platform 200 may also connect with the PSTN 120. 

Figure 4 shows the aircore platform 200 used in conjunction with fixed 
wireless local loop customers. In Figure 4, the fixed wireless local loops 151 include 
a number of fixed customers in each of the local loops 151. The local loops 151 
provide telephony services to fixed wireless customers in their respective loops. The 
services are provided via a fixed terminal (not shown) that is attached to a location 
and typically extends via a standard two-wire or similar connection to an analog 
telephone within the location. Call processing and feature management are handled 
by the aircore platform 200 as for a normal wireless customer. The only difference for 
the aircore platform 200 is that the area of operation for the fixed terminal does not 
change. Even though the terminal is using a wireless interface for communications, 
the terminal's location remains fixed. The aircore platform 200 processes the calls to 
and from the customer in the same manner as with mobile wireless calls because the 
air interface determines the protocol and the feature set that is to be used to 
communicate with the customer's fixed terminal. The protocol can be any of the 
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1 wireless protocols (CDMA, TDMA, AMPS, GSM). To limit the area of 

2 communications for a particular fixed terminal, the aircore platform 200 can be 

3 configured to only allow service to a particular location area for a particular fixed 

4 terminal. 

5 The aircore platform 200 provides a full range of mobile services to a wireless 

6 ' local loop, or location area. In Figure 5, the aircore platform 200 is shown providing 

7 mobile services to a wireless local loop 152 and a wireless local loop 153. In this type 

8 of mobility situation, customers may move with their wireless terminals in a given 

9 wireless local loop or location area. Movement outside of the location area is not 

10 supported for these types of terminals. A typical implementation of this type of 

1 1 mobility is provided in a village or town scenario where the coverage is disjointed 

12 from other parts of the telecommunications system. 

13 Figure 6 shows a system level mobility scenario that permits mobility for the 

14 customer across all location areas under the control of the local aircore platform 200. 

15 In Figure 6, the location area 154 and the location area 155 are both serviced by the 

16 aircore platform 200. Moreover, customers in the location area 154 may freely move 

17 through the location area 154 and the location area 155 and maintain wireless 

1 8 communications with the aircore platform 200. This type of scenario can be found in 

19 multiple towns or villages where a common aircore platform 200 is shared and the 

20 coverage is contiguous or there is a considerable amount of allowable travel between 

21 the locations covered by the system. 

22 Figure 7 shows a full scale mobility scenario. In Figure 7, the aircore platform 

23 200 communicates with a public land mobile network (PLMN) 158 and with local 

24 wireless loops 156 and 157. The local wireless loops 156 and 157 also communicate 

25 with the PLMN 158. This configuration provides for incoming and outgoing roaming 

26 traffic to and from the local aircore platform 200 to other switching centers, which 

27 may also be aircore platforms 200. 

28 Figure 8 is a block diagram of a wireless network architecture according to the 

29 invention. In Figure 8, the aircore platform 200 includes a MSC/VLR 210\ a home 
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location register 224, an authentication center 226, and an equipment identification 
register 225. The aircore platform 200 communicates with the base station system 
(BSS) 104' using one or more protocols including GSM, CDMA, TDMA, and AMPS. 
The aircore platform 200 also communicates with the PSTN 220 and other elements 
of the wireless network. An alternate mobile telecommunications switch is also 
shown in Figure 8. A MSC/VLR 210" is coupled to the PSTN 220 and the BSS 104". 
However, other modular components used in the mobile telecommunications 
environment are located remotely from the MSC/VLR 210' '. A system management 
controller 230, a home location register 221, an equipment identification register 222 
and an authentication center 223 may be physically separated from the MSC/VLR 
210" However, the functions of these modular components remain the same, 
whether they are located with or remote from the MSC/VLR 210' and 210", 

13 respectively. 

14 Figure 9 shows the functions and connections of the aircore platform 200. In 

15 Figure 9, the visitor location register, the home location register, the equipment 

16 identification register and the authentication center are shown co-located with the 

17 MSC 210. The aircore platform 200 connects to the PSTN 120 via a T-l/E-1 line. 

18 The aircore platform 200 is adapted to receive land-line originated telephone 

19 messages. The aircore platform 200 can then send a connect message to an 

20 appropriate base station system. The aircore platform 200 also allows intersystem 

21 connection to an IS-41 wireless network 170 via a SS-7 link and a GSM wireless 

22 network 160 via a SS-7 link. Optionally, these links may be based on other 

23 communication carriage mechanisms such as IP, X.25, frame relay, or asynchronous 

24 transfer mode (ATM). 

25 The aircore platform 200 provides for intrasystem, or base station, wireless 

26 coromunieation using GSM protocols via a GSM BSC 240 and BTS 241. The aircore 

27 platform 200 provides wireless cornmunications using CDMA and TDMA vta a IS- 

28 634 link, an 1S-95A BSC 244, a BTS 243 and a IS-136 BSC 242 and BTS 249. The 

29 aircore platform 200 communic^es with an AMPS BTS 246 using the ISDN PRI + or 
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the IS-634 protocol. The aircore platform 200 provides communications with a 
private branch exchange (PBX) 248 via T-l/E-1 lines. The aircore platform 200 also 
provides for connection to a billing system 260 using TCP/IP protocols, for example, 
and for voice mail and messaging functions via voicemail module 250. 
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PROTOCOL 
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Base Station 


GSM "A" (Series 4 and 8) 


GSM Network 


s 




IS-651 & J-STD 


US GSM based PCS 


9 




1O-0.34 (1o-13o) 


DAMPS Network 


10 




TO £1 A /TO C\ C A \ 

IS-634 (IS-95A) 


CDMA Network 


11 




IS-634 (AMPS) 


Analog Network 


12 




ISDN PRI+(AMPS) 


Analog Network 


13 


Intersystem 


GMS 09.02 


GSM Network 


14 




IS-652 


US GSM based PCS 


15 




ANSI-41 


DAMPS, DCMA, AMPS Network 


16 


PSTN 


T-l 


T-l Interface (various protocols) to the PSTN 


17 




E-l 


E-l Interface (various protocols to the PSTN 


18 
19 


Tandem 


T-l 


T-l Interface tandem call traffic between local PBX 
and the PSTN 


20 
21 




E-l 


E-l Interface tandem call traffic between local PBX 
and the PSTN 


22 


Voice Mail 


T-l 


T-l Interface to voice mail system 


23 




E-l 


E-l Interface to voice mail system 


24 
25 


Billing 
Center 


TCP/IP 


Interface for the transfer of Call Detail Records 


26 
27 

1C 


NMC/OMC 


TCP/TP 


Interface for the exchange of Network Management 
related information 



Table A shows a list of interfaces from the aircore platform 200 and the 
functionality each of the interfaces adds. A Network Management Center/Operations 
and Maintenance Center (NMC/OMC) 262 communicates with the aircore platform 
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1 200 using TCP/IP protocols, for example. The billing system 260 and the NMC/OMC 

2 262 may also communicate with the aircore platform 200 using CCITT X.25 

3 protocols. 

4 Figure 10 is a block diagram of the aircore software architecture 300. In 

5 Figure 10, the architecture 300 is shown including a system control module SCM 

6 layer 3 10, a call processing control module handling the real time application layer 

7 400, and a device handler layer 500. The SCM layer 310 maintains responsibility for 

8 non-real time related applications, such as report management and configuration. The 

9 SCM layer 3 10 generates and collects various types of report data, system 

10 configuration information and system maintenance procedures. The SCM layer 3 10 

11 may be logically and physically separated from the rest of the aircore software 

12 architecture 300. 

13 The call processing control module of the real time application layer 400 

14 handles the application layer tasks that are real-time related. At the real time 

15 application layer 400 of software, direct knowledge of specific protocols is not 

16 required. Instead, this layer handles functions from a generic standpoint. For 

17 example, a call processing state machine processes mobile originated call set up in th< 

18 same manner regardless of the type of interface used to connect to the base station 

19 equipment The event set and state machine commonality allow lower layers of 

20 software to change without effecting the call processing control module of the real 

21 time application layer 400. 

22 The device handler layer 500 is the lowest layer of software in the aircore 

23 software architecture 300. The device handler layer 500 contains the specific softwai 

24 applications to receive and transmit protocol specific messages. 

25 The SCM layer 3 10 includes a control panel (CTL) 3 12, which is the father 

26 process of all the other processes in the system. The CTL 312 is responsible for 

27 startup and auditing of the overall aircore software architecture 300. Once started, th 

28 CTL 3 12 is only involved in limited auditing functions. 

-15- 



RM.<^nnnir> <wo ooa693SA1_ia> 



WO 00/46938 



PCT/USOO/02797 



A call record management (SCR) 3 14 tracks the call report data generated in 
the system. These records can be used for billing tracking, system tendencies, or 
prepaid type of access. Call records are archived and the files rotated periodically. 
For example, the files may be rotated hourly. Real-time output is accessible via 
standard output options such as a printer or a screen output. Archived output is 
accessible on screen, or may be accessed over a standard TCP/DP network or dial up. 

An operational measurements manager (OMM) 316 is responsible for tracking 
system counters. A count is defined as the occurrence of a particular situation. Each 
time the situation occurs, the counter is incremented. Operational measurements are 
archived and the files rotated periodically. For example, the files may be rotated 
hourly. Each time a new file is created, each of the counters is reset to zero. This type 
of data is captured to allow an operator to track system performance and tendencies 
over time. Operational measurements are archived into files rotated periodically. 
Real-time output is accessible using standard output options such as a printer or a 
screen output. Archived output is accessible on-screen or can be accessed over a 
standard TCP/IP network or dial up. 

A real-time log report manager (RTL) 318 tracks system level reports. System 
level reports are generated to notify an operator of certain tasks or situations occurring 
on the aircore platform 200. For example, at the top of the hour, the system level 
audit log reports may be output. Log reports range from reporting normal system 
maintenance events to system status changes. Log reports are archived into files 
rotated periodically. Real-time output is accessible using standard output options such 
as a printer or a screen output. Archived output is accessible on screen or can be 
accessed over a standard TCP/IP network or dial up. 

An auto removal process (AUTO) 322 is responsible for automatic removal of 
outdated archived report files. Automatic removal may occur on a periodic basis, 
such as monthly. 

A network management database administration (NMS) 324 allows access to 
databases that provide configuration information for routing, rating and language for 
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mo bile devices. A system conf.gura.ion (SYSCFG) 326 allows access to the 
configuration of system telephony hardware resources. A system maintenance 
(SYSMTC) 328 allows access to operator-initiated maintenance procedures. 

A visitor location register interface VU 332 provides the operator access to a 
visitor .ocation register. A home location register interface (HU) 334 provides an 
operator interface to the home location register and authentication center informal. 

equipment identity register interface (EH) 336 provides an operator interface to the 
equipment identity register. The V1J 332, HLi 334 and EII 336 may be implemented 
as a graphic*! user interface® (GUI) or as batch type operations, These interfaces 
10 will be described in more detail later. 

The call processing control module (CPCM) of the real time, application layer 
400 includes arecovery and startup (REQ 402, which is the father process of the 
software subsystems in the real time application layer 400 and at the device handler 
iayer 500. The REC 402 manages the maintenance states for the trunk and srgnahng 
facilities in the real time application layer 400. The REC 402 interfaces with each o 
the device handlers in the device handler layer 500 for maintenance and status as well 
as with graphical user interface-based applications in the SCM layer 3.0 to process 
operator initiated maintenance requests. The REC 402 also initiates an and., of aU 
real time application layer 400 subsystems. The audit may run every two mrnutes, for 
example, and provides assurance mat all subsystems are mnning properly 

A fault analysis unit (FAU) 404 is responsible for the collection of all log 
reports and operational measurement related data created within the CPCM 400. The 
FAU 404 to real-time layer interface is a singular path for mis information to pas, 
All CPCM 400 subsystems have access to pass events to the FAU 404 for tins 

The timer manager (TIM) 406 provides timing facilities to call processes 
control module subsystems in the aircore platform 200. The TIM 406 is used for 
application level timers that operate on aone second or greater granularity. Tuners 
are stored in a list and are tracked until they are released or until they expire. Tuners 
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1 requiring finer granularity or those that are specific to a particular subsystem's 

2 requirements are controlled locally either in the subsystem or on board in the 

3 hardware. The timers associated with the aircore platform 200 will be described later 

4 in more detail. 

5 A resource manager (RCM) 408 is used to manage base station resources 

6 connected to the aircore platform 200. The RCM 408 has the capability to configure, 

7 download, and track the state of individual cell site components as well as the base 

8 station as a whole. 

9 A CPCM call record management (CCR) 412 module provides for local 

10 collection of call detail record (CDR) information for calls in progress. When calls 

11 are completed, the CDR information is transferred from the CCR 412 to the SCR 3 14 

12 in the SCM 310, where the call record data is processed and stored. 

13 A cal l processing manager (CPM) 414 provides the processing required for all 

14 communication channel establishment, tear down, feature processing and hand off 

15 control. The state machines in place in the CPM 414 are based on a half-call model. 

16 Each party in a session moves through a defined set of states based on received and 

17 sent events, and timers used. Each side of a call steps through its own state. The two 

18 sides of the call progress together. For a basic call setup, the state of one side of the 

19 call is never more than one step ahead or behind the state of the other side. In the 

20 CPM 414, each call placed requires the creation of a session object. This object is 

21 created based on an index number created from the board span and channel used by 

22 the originator of the call. The session adds and removes call objects as dictated by the 

23 progress of the call. The reference number for the session is always based on the 

24 originator's board span and channel. However, the session may also be indexed via 

25 the index number of the board, span and channel of any of the involved parties. 

26 A hand off processor (HOP) 416 is responsible for the preprocessing required 

27 for hand off or hand over (GSM). Based on the technology and the involvement of 

28 intersystem border cells, the level of involvement of the HOP 416 varies from one air 

29 interface protocol to the next. However, like other modules performing specific 
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1 functions, the unique aspects of the protocol are handled internally in the HOP 416. 

2 The interface to the CPM 414 for hand off processing is made generic. Preprocessing 

3 in relation to handoff processing refers to the collection of data and the decision 

4 process used to determine the appropriate base station to target for the hand off. This 

5 entire process has been formed into a generic procedure within the aircore software 

6 architecture 300. 

7 A tone and announcement manager (TAM) 418 is responsible for management 

8 of the digital signal processor resources in the system used for playing tones and 

9 announcements. The TAM 418 interacts directly with the CPM 414 to provide the 

10 necessary digital signal processor allocations. The digital signal processors are 

1 1 controlled by components of the device handler 500. Direct communication to the 

12 device handler from the CPM 414 is avoided so that the CPM 414 does not have to 

13 maintain direct knowledge of the current digital signal processor configuration and 

14 allocations. 

15 A visitor location register (VLR) 422 is responsible for establishing and 

16 maintaining a VLR database for the aircore platform 200. As shown in Figure 10, the 

17 VLR 422 is co-located with the aircore platform 200. However, the VLR 422 could 

18 be located remotely from the aircore platform 200. The VLR 422 is a collection of 

19 customer profiles for users currently active on the system. The VLR 422 is a dynamic 

20 database created and maintained while the aircore platform 200 is running. The VLR 

21 422 communicates with threads inside an Advanced Intelligent Message Handler 

22 (AIM) 430, which will be described later, for real-time application messaging. Any 

23 communications to or from the VLR 422irom the CPCM 400 are received via the 

24 AIM 430. Communications with the VLI 332 are limited to those necessary to allow 

25 for the display of individual customer profile information, listing the current profiles 

26 in the VLR 422 and allowing an operator the ability to update customer profiles from 

27 the VLR database. 

28 A home location register/authentication center (HLR) 424 is responsible for 

29 establishing and maintaining the HLR database for the aircore platform 200. As 
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1 shown in Figure 10, the HLR 424 is co-located with the aircore platform 200. 

2 However, the HLR 424 could also be located remotely from the aircore platform 200. 

3 In addition, the functions of the HLR 424 could be carried out in separate HLR and 

4 AC modules. The HLR 424 includes a collection of permanent customer profiles for 

5 users homed on the system. The HLR 424 is a static database that tracks the current 

6 location of a customer in addition to the individual profile parameters and status of 

7 customer-related features. The HLR 424 communicates with the AIM 430 for real- 

8 time application messaging. Any communications to or from the HLR 424 in the 

9 CPCM 400 are received via the AIM 430. Communications with the HLI 334 are 

10 limited to those necessary to allow for the manipulation of individual customer 

1 1 profiles, listing the current customer profiles in the HLR 424, and allowing an 

12 operator to update the customer profiles. 

13 The HLR 424 also contains the functionality to perform the advanced security 

14 calculations used in digital air interface protocols. These calculations are based on a 

15 piece of secret data combined with a random number to yield a result that only has 

16 meaning to the authentication center and the mobile unit. This functionality is 

17 included in the HLR database and is integrated as part of the customer profile. The 

1 8 actual comparison of data is done in the AIM 430 or in the HLR 424 itself, depending 

19 on the protocol. Since the authentication center is integrated in the HLR 424, 

20 communications with the authentication center all funnel through the HLR 424. The 

21 authentication process will be explained in more detail later. 

22 An equipment identity register (EIR) 426 is responsible fof establishing and 

23 maintaining an EIR database for the aircore platform 200. The EIR database is a 

24 collection of the serial number information for mobile telephone handsets and other 

25 equipment in the system. The EIR 426 normally maintains at least three lists: 

26 White - range listing of valid international mobile equipment identities 

27 (International Mobile Equipment Identity (IMEI)) (serial numbers). 

28 Gray - list of individual serial numbers of questionable phones. Usage is 

29 operator dependent. 



-20- 



BNSDOCID: <WO 0046938A1JA> 



PCT/USOO/027 4 J7 

WO 00/46938 



1 

2 the system. 



Black - list of individual serial numbers of equipment prohibited from using 



3 
4 
5 
6 
7 
8 



LI 
12 
13 
L4 

15 (DH-7) 510 



The SIR 426 is used with GSM-type systems. However, application to other 
system protocols may aiso he accomplished. The ETR 426 comraunic.es with Ute 
lot 430 for real-time application messaging. Any communications to or » the BR 
426 from the CPCM 400 are received via the AIM 430. Communications between the 
EIR 426 and the EH 336 are Mmited to those necessary to aUow for the manrpulation 
of us. information. This includes allowing an operator to add, modify and delete from 

9 the information the ETR database. 

Thedevicehandler500ineludesapor«ionofmeAIM430. Thedev.ce 

handier 500 includes a device handler for digital CAS interface ( DHT>) 501 a device 
handier for voice input and output devices (DHA) 502, a device handler for ISDN 
m,erfaces(DH I ,5 0 3.adevicehand,erforconferenc fi <DHC)504,andadev^ 

handler for timers (DHT, 505. The AIM 430 also includes a devrce handler for SS-7 

Fi^rre 11 isalogical diagram of the advanced intelligent message handler 
(AIM) 430 The AIM 430 provides for advanced protocol processing, message 
v^v V , Thp> ATM 430 is built around 

routing and system interfaces for the wireless network. The ATM 43U 

tire steps required .o estabUsh call processing, mobili<y. and servicing m a wieless 
environment. The basic approach of the AIM 430 is to use a multi-thread t0 
isolate protocols andfunctions quired for the mobUity environment. BachduTerent 
protocol family supported by the aircore platform 200 is handled by a thread 
Ldtanr constructed for me message sent and suae machine for mat protocol 
^ CoLunications to various software entities such as the VLR, HLR, and ETR 
tone! through the AIM 430 subsystem. This approach is taken to remove the 
knowledge of the low layer message destination fromeach o, mose^tities Thrs 
approach a,so aUows for the is„,ation of protocol specifics to the ATM 430 layer of 
soLare. Finally, mis approach allows for the seamless separation of mese functions 
„ physically separate entities without effecting the application software. The 
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1 following is an example of the benefit of this approach: When the CPM 414 needs to 

2 request the current location of a subscriber from the HLR 424, the message is sent to 

3 the AIM 430 subsystem without the direct knowledge of the HLR location or the 

4 protocol used to communicate with the HLR 424. The AIM 430 handles the routing 

5 (either internal or external) and the selection and construction of the appropriate 

6 message based on the protocol. 

7 In Figure 1 1, a main AIM thread 438 is shown along with subordinate threads 

8 431-436. In addition, a common memory 439 is used to share data related to a 

9 transaction or connection between the subordinate threads 43 1-436 and the device 

10 handler for SS-7 (DH-7) 510. Since each of the procedures followed for call 

1 1 establishment, location updating, etc., involve multiple threads and actions, the 

12 common memory 439 optimizes the performance of the AIM 430 by reducing the 

13 copying of data between threads while at the same time allowing data sharing across 

14 all of the threads by simply passing a pointer. 

15 The A-interface message handler (AMH) 431 provides message decoding and 

16 encoding for interface processing between an external base station and the aircore 

17 platform 200 event structures and state machines. 

18 Figure 12 is a block diagram of the logical architecture of the A-interface 

1 9 message handler AMH 43 1 . Communications received from a base station interface 

20 are first interpreted by the AMH 43 1 . The encoding and decoding specification for a 

21 particular protocol are contained in dynamic linked libraries 441 and 442 that are 

22 linked to the AMH 43 1. Each variant of the A-interface has its own unique set of 

23 builder/decoder dynamic linked libraries. Each type of A-interface utilizes its own 

24 instance of the AMH 43 1. Also shown in Figure 12 are timers 443j through 443 n . 

25 The timers 443j-443 n , which control operations of state machine call processing for a 

26 given connection, will be described in more detail later. 

27 Figure 13 is a logical block diagram of the ISUP message handler (SMH) 436 

28 logical architecture. The SMH 436 provides appropriate message conversion between 

29 the application programming interface and the internal aircore subsystem event 
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1 structures. As shown in Figure 13, the SMH 436 is logically linked to the board levels 

2 at boards 444 ,-444,,. 

3 Figure 14 is a logical block diagram of the intersystem message handler (IMH) 

4 432 architecture. The IMH 432 encodes and decodes protocol messages related to a 

5 mobile unit from an external communications system. These messages are called 

6 Mobile Application Part. The encoding and decoding specifications for a particular 

7 protocol are contained in the dynamic Unked nbraries 445 and 446 that are linked to 

8 the IMH 432. Each variant of the MAP interface has its own unique set of 
builder/decoder dynamic Unked libraries. Each type of MAP interface utilizes its own 
instance of the IMH thread 432. Also shown linked to the IMH thread are timers 
44 7l -447 n . The function of the timers 447 will be described in more detail later. 

12 1 An authentication and registration processing (ARS) thread 434 (see Figure 

13 11) provides appropriate calculations, comparisons and invocations of the required 

14 authentication for a given base station interface. A paging processing (PAG) thread 

15 435 (see Figure 1 1) provides the processing necessary for paging in the AirCore 

16 system. Pacing is the mechanism for locating and starting the process of notifying a 

17 mobile unit of an mcorning call or message. 

18 Figure 15 is a logical block diagram of the device handler for voice I/O 

19 devices (DHA) 502. The DHA 502 provides control of voice I/O resources in the 

20 aircore platform 200 that are used for playing tones and announcements. The DHA 

21 502 is a single process that spawns individual threads for each digital signal processor 

22 that is accessible. As shown in Figure 15, the DHA 502 spawns digital signal 

23 processor threads 522, through 522 n . The aircore platform 200 uses the first five 

24 digital signal processors in the system to play standard tones. These tones are 

25 accessible to all ports on the system. This approach satisfies the requirements of 

26 playing ring-back or busy tones to all ports simultaneously. After the first five digital 

27 signal processors, the remaining digital signal processors are allocated to a pool that 

28 may be used in real-time call processing to play tones or announcements for call 

29 progressing. The five digital signal processors are used for the standard tones of ring 
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1 back, busy, fast busy, dial tone and confirmation beep. To play announcements for 

2 call progressing, the DHA 502 works with the tone and announcement manager 

3 (TAM) 418 (not shown, see Figure 10), which receives its commands from the CPM 

4 414. 

5 Figure 16 shows the device handler for digital channel associated signaling 

6 (CAS) interface (DHD) 501 in more detail. Channel associated signaling is a method 

7 of signaling in telecommunications where a portion of each channel between two 

8 entities is allocated for the carriage of the signaling and supervision in formations. 

9 The DHD 501 is a multi-thread, multi-process subsystem that provides for CAS 

10 processing. 

1 1 Each channel in the DHD 501 is allocated a thread for processing the low layer 

12 protocol state machine. As shown in Figure 16, spans 51 1 r 51 l n are associated with 

13 processing threads 512 r 512 24/32 and 513 r 513 24/32 . The top layer process in the DHD 

14 501 architecture is responsible for the interworking between the thread output in the 

15 real time application layer 400. 

!6 Figure 17 shows the device handler for ISDN interfaces (DHI) 503. The DHI 

17 503 is a multi-threaded, single process subsystem that provides processing for 

18 common channel signaling interfaces. The DHI 503 is used internally in the aircore 

19 platform 200 to handle facilities (T-l or E-l) that use common channel signaling 

20 methods. Common channel signaling provides a single signaling channel for the 

21 control of signaling and supervision information for many channels of resources (e.g., 

22 a single channel is used to pass the appropriate signaling for all of the associated 

23 traffic channels). Typically the signaling channel is based on an industry signaling 

24 method such as SS-7, LAPD, or TCP/IP. In the DHI 503, a top layer process is 

25 , responsible for communications to the internal aircore platform 200 subsystems, 

26 Linked to the DHI 503 are board level threads 520 r 520 n . The board level threads 

27 520,-520 n are used to handle individual boards in the aircore platform 200. 

28 Figure 18 is a logical block diagram of a device handler for SS-7 (DH-7) 5 10. 

29 The DH-7 510 exists for the purpose of handling the board level API for the SS-7 
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1 links in the system. The main tasks of the DH-7 5 10 are the basic assignment of 

2 threads to the SS-7 links and assuring proper message routing for inbound messages to 

3 the internal aircore subsystems and threads. Each SS-7 link established in the system 

4 has its own link level thread that exists as a subordinate thread to the main DH-7 510 

5 thread. 

6 Figure 19 is a logical block diagram showing interlayer communications 

7 among the SCM layer 310, the real time application layer 400 and the device handler 

8 layer 500. In Figure 19, a two-way communications path 350 between the CTL 312 

9 and the REC 402 is used to start the real time application layer 400 and report the 

10 appropriate status information. One-way path 351 is used to transfer CDRs from the 

1 1 real time application layer 400 to the SCM layer 310. One-way path 352 between the 

12 FAU 404 and the RTL 318 is used to transfer report and operational measurement 

13 pegs from the real time application layer 400 to the SCM layer 310. One-way path 

14 353 between the SYSMTC 328 and the REC 402 is used to pass maintenance related 

15 commands to the real time application layer 400 from the SCM layer 3 10. Two-way 

16 path 354 from the VLI 332 to the VLR 422 is used to exchange information between 

17 the VLR 422 and the VLR graphical user interface 332. Two-way path 355 between 

18 the HLI 334 and the HLR 424 is used to exchange information between the HLR 424 

19 and the HLR graphical user interface 334. Two-way path 356 between the EH 3^6 

20 and the EIR 426 is used to exchange information between the EIR 426 and the FJR 

21 graphical user interface 336. 

22 Path 450 between the REC 402 and subsystem at the device handler layer 500 

23 is defined for startup, status and maintenance communications used to interact with 

24 the telephony board level hardware. The REC 402 communicates directly with all 

25 device handler level subsystems with the exception of the DH-7 510, which is handled 

26 via communications with the AIM 430. Two-way path 451 between the CPM 414 and 

27 the device handler layer 500 is established for the exchange of messages for call 

28 processing related activities in the aircore platform 200. The CPM 410 communicates 

29 directly with all device handler 500 level subsystems with the exception of the DHA 
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1 502 and the DH-7 510. Communications path 452 between the TAM 418 and the 

2 DHA 502 provides for the allocation and deallocation of voice I/O resources for tones 

3 and announcements. Much like trunk groups that abstract the physical location of 

4 trunks, this level of communication abstracts the physical location of the digital signal 

5 processors used for playing the tones and announcements. Communications path 453 

6 between the AMH 431, SMH 436, 1MH 432 and the DH-7 510 provides for 

7 communications between the SS-7 links and the builder/decoder threads in the AIM 

8 430. 

9 Figure 20 is a logical representation of the HLR 424. The HLR 424 contains 

10 permanent data that is independent of the customer's present location, plus temporary 

1 1 data such as the current location of the system where the mobile unit is registered and 

12 the addresses of service centers that have stored short messages for mobile stations. 

13 An example of such a message is a request to turn on a voice message waiting lamp 

14 indicating that a voice message has been stored for the mobile station user in a voice 

15 messaging system. These addresses are erased after the short messages have been 

16 delivered. 

17 As shown in Figure 20, the HLR 424 includes customer profiles 460j for each 

18 mobile customer. The customer profile 460! includes a customer data module 461 . 
19^ The customer data module 461 includes a customer group identification, which is a 

20 four digit number specifying the routing translations index for the customer. The 

21 number must be previously configured in a routing translations data base via a routing 

22 administration window. The customer data module 461 also includes the International 

23 Mobile Customer Identity (IMSI), the International Mobile Equipment Identity (IMEI) 

24 or Electronic Serial Number (ESN), which is the serial number of the handset 

25 hardware, and the Kj, or A-key which is the key used for authentication calculations. 

26 The customer data module 461 also includes the name of the customer, the language 

27 for customer announcements, a three to five digit carrier ID identifier for long distance 

28 carrier code associated with the customer, a check box for calling card features and a 

29 prepaid feature. A call offering module 462 includes an indication of current features 
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1 such as call forwarding unconditional (CFU), call forward busy (CFB), call 

2 forwarding no reply (CFNRy), and call forwarding not reachable (CFNRc), and call 

3 forwarding default (CFD). 

4 A VLR/MSC data module 463 indicates the VLR in and the MSC associated 

5 with the current area of operation of the customer. A personal identification number 

6 (PIN) data module 464 indicates if the customer uses a PIN when accessing the 

7 system for calling card or long distance calls and the four digit PIN number associated 

8 with the customer. A protocols module 465 is used for multi-mode customers to 

9 determine the capabilities of the customers 1 units. The protocols may include, but are 

10 not limited to, TDMA, CDMA, GSM and AMPS. A call restriction module 466 

1 1 stores features for restricting the calling capabilities of the customer to and from the 

12 network. The call restriction features include baring of all outgoing calls, suspended 

13 service (no calls allowed), baring of all outgoing international calls, baring of all 

14 incoming calls, baring of all outgoing international calls except those to the home 

15 PLMN country and baring incoming calls to a customer when they are roaming to 

1 6 another system. 

17 A call features module 467 indicates the set of features allocated to a 

18 customer. The call features include call hold, multi-party calling, 3 -way calling, 

19 roaming, call waiting and access to sending and receiving short messages. A line 

20 identification module 468 identifies features that provide/restrict calling and called 

21 number information to various parties in a call. The line identification features 

22 include calling line ID presentation, calling number presentation, connected line ID 

23 presentation, calling line ID restriction, calling number restriction, and connected ED 

24 restriction. 

25 A message center data module 469 provides for storage of short messages 

26 pending delivery to a customer's mobile unit. 

27 The HLR 424 may also include an authentication center. The authentication 

28 center provides authentication and encryption parameters to insure that a mobile 

29 customer cannot falsely assume the identity of another mobile customer. The 
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1 authentication center also provides data for encrypting the voice or data and control 

2 signals transmitted via the air between the mobile station and the serving base station 

3 subsystem. A GSM reference model prescribes digital communications over the radio 

4 channels. Since it is possible to surreptitiously listen to these channels, encryption 

5 becomes desirable for the link between the mobile station and the radio receiver at a 

6 base station serving that mobile station. Any public or proprietary encryption 

7 algorithm known in the art can be used with the aircore platform 200. 

8 The calculations for the authentication center use the secret key information 

9 associated with the subscriber and the protocol specific calculations. The HLR 424 

10 pre-processes these authentication calculations and stores them as part of the 

1 1 subscriber profile. As required, this information is shared with the servicing 

12 MSC/VLR to authenticate the mobile unit as it accesses the system. 

13 The VLR 422 contains current data for each active mobile customer, including 

14 that customer's mobile station present or most recently known location area, the 

15 mobile unit's on/off status, and security parameters. The VLR 422 is logically 

16 constructed in the same manner as the HLR 424. 

17 The HLR and VLR databases both simultaneously accommodate customer 

18 profiles from any interface protocol. There are two significant classifications of 

19 profile types, based on the intersystem protocol used to transmit and receive profile 

20 information over the wireless network. Both GSM and IS-41 based networks share 

21 common information in the customer profile structures, but each profile type also 

22 requires fields and information that are unique to that particular protocol type. The 

23 HLR and VLR databases provide for this by an internal structure that uses a common 

24 top level header for the common data and then protocol specific attachments. This 

25 internal structure is shown in Figure 21. A GSM side 417 and an IS-41 side 419 are 

26 used with the VLR and HLR databases. A common data header 427 is used for both 

27 GSM and IS-41 profile information. A GSM specific data area 428 is used for GSM 

28 specific data. An IS-41 specific data area 429 is used for IS-41 specific data. The 

29 common data header 427 allows the two sides of the database to use common search 
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1 routines while the specific data areas allows for the storage of data that pertains to a 

2 specific protocol alone. 

3 A description of the timers used by the MSC 210 will now be provided. A call 

4 proceeds from initiation to connection through a series of steps. The time associated 

5 with this call set up and connection is usually short. Nonetheless, one or more voice 

6 channels may be reserved at the start of the call set up. If the call will not connect, 

7 some mechanism is desirable to release these resources as quickly as possible so that 

8 they may be used by other customers. Furthermore, during the time that the mobile 

9 unit is held waiting for an incoming call, the mobile unit cannot call out or receive 

10 other incoming calls. To free up resources and to release the mobile unit, the TMR 

1 1 437, in conjunction with the TIM 406 (see Figure 10) includes a number of timers that 

12 may be established at various points in the call set up and connect process. The timers 

13 are generally set based on a message from the AMH 431 or similar interface. 

14 A timer may be set when a device handler such as the device handler 5 10 

15 requests a BSC 105 to assign a channel. In this case, the AMH 431 sends a message 

16 to the TMR 437 to set the timer. If an assignment is not completed within the time 

17 limit of the timer, the call connection process ends. If the assignment is completed 

18 before expiration of the timer, the AMH 43 1 sends a message to the TMR 437 to 

19 release the timer. 

20 A timer may be associated with a connect message sent to the BSC 105 by a 

21 device handler. If a connect acknowledgment message is received by the device 

22 handler, the AMH 43 1 will send a timer release message, allowing the call connection 

23 to complete. Similarly, a timer may be set to time out a make call command, a paging 

24 message for a mobile terminated call, a disconnect message (GSM) or release message 

25 IS-634) for PSTN and mobile originated calls, and a clear command to release a 

26 channel during a call disconnect sequence. Other timers may be used to ensure 

27 resources are returned for assignment to other calls. 

28 Managing the location of a customer ensures the proper connection of the 

29 customer's mobile unit for both mobile initiated calls and mobile terminated calls. In 
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1 Figure 22, the authentication and registration (ARS) 434 thread is shown in 

2 communication with the common memory 439. The common memory 439 includes 

3 the data relevant to the mobile unit and the state machine relevant to the protocol and 

4 the transaction being performed. The ARS 434 maintains communications with the 

5 AMH 431 and the IMH 432 to track ongoing transactions, to compare SRES, to send 

6 TMSI to the mobile unit and to provide ciphering information to the AMH 43 1 . The 

7 IMH 432 provides connections to the VLR 422 and HLR 424 for obtaining customer 

8 profile information. 

9 The call processing module (CPM) 414 processes calls according to one of 

10 several state machines. A state machine exists for each half of every call processed 

1 1 through the aircore platform 200. A separate state machine exists for mobile 

12 originated call processing, PSTN originated call processing and mobile terminated call 

13 processing, for example. Figures 23-25 are examples of state machines used in 

14 processing calls at the aircore platform 200. Figure 23 is a state machine 600 for 

15 mobile originated call processing. In Figure 23, eight states are possible: idle (S 1), 

16 wait for UUI (S2), wait for page response (S3), wait for alert (S4), wait for connect 

17 (S5), voice (S6), wait for handoff confirm (S7), tone and announce (S8), and wait for 

18 call cleared (S9). The state machine 600 shows the allowed transitions between 

19 states. Starting in idle S 1, the state machine 600 can transition to state wait for UUI 

20 S2 or wait for call cleared S9. The state machine 600 transitions to wait for UUI S2 

21 based on reception of the mobile customer's profile when a CALL.RECEIVED 

22 message is received. The state machine 600 transitions from idle S 1 to wait for call 

23 cleared S9 based on the mobile customer profile indicating a particular call restriction 

24 or if the call fails before routing. With the authentication previously set up with the 

25 A-interface protocol, this transition may not be possible. 

26 In the wait for UUI state S2, the state machine 600 can transition to the wait 

27 for alert state S4. This transition is based on receiving the ROUTE.CALL message. 

28 The aircore platform 200 proceeds with making the call out to the called party if the 

29 call type is direct dial (DD) in the routing translations or when a call delivery to a 
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1 mobile unit or another system is required. The CPM 414 then sends a MAKE_CALL 

2 message. Next, the state machine 600 can transition from the wait for UUI state S2 to 

3 the wait for page response S3 based on receiving a ROUTECALL message. A 

4 PAGE_MOBILE message is sent to the PAG 435. The transition to this state is based 

5 on a call type of MOB in the routing translations and finding that the called mobile 

6 unit is operating in the aircore system. The state machine 600 transitions from the 

7 wait for UUI state S2 to the tone and announce state S8 if the dialed number received 

8 from the originating mobile unit fails to translate properly or if there is a restriction on 

9 the called mobile unit The originating mobile unit is then connected to a tone. This 

10 transition could also occur by the CPM 414 receiving a PAGEJRESPONSE message 

1 1 with a time out indication. Finally, the wait for UUI state S2 can transition to the wait 

12 for call cleared state S9 based on receiving a disconnect from the mobile unit. When 

13 the message CALL_DISCONNECTED is received at the CPM 414, a CLEAR_CAIX 

14 message is sent. 

15 The state machine 600 transitions from the wait for page response S3 to the 

16 wait for alert state S4 based on receiving a PAGE_RESPONSE message. A 

17 MAKE_CALL message is then sent and the CPM 414 proceeds with an ISDN state 

18 machine 600. The wait for page response state S3 transitions to the tone and 

19 announce state S8 along transition path T8 based on receiving a time out for a page 

20 response. The CPM 414 then provides a time out announcement or tone to the calling 

21 party. The state machine 600 transitions from the wait for page response state S3 to 

22 the wait for call cleared state S9 along transition path T9 based on receiving a 

23 disconnect from the originating mobile unit. A C ALL_DIS CONNECTED message is 

24 received at the CPM 414 and a CLEAR_CALL message is sent. The PAG thread 435 

25 will time out and clear the page request data for the call. 

26 The state machine 600 transitions from the wait for alert state S4 to the wait 

27 for connect state S5 along transition path T10 based on receiving an alerting 

28 indication from the called party. The alerting indication is passed to the mobile 

29 customer's side of the call. The CPM 414 receives the CAIi_ALERTTNG message 
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1 from the called party and sends an AJLERT_CALL to the originating mobile unit. The 

2 transition from the wait for alert state S4 to the voice state S6 occurs along transition 

3 path Tl 1 based on receiving a connect indication from the called party. The protocol 

4 allows a CONNECT message to be received without receiving alerting. The CPM 

5 414 receives a CALL_CONNECTED message from the called party and sends a 

6 CONNECT_CALL message to the originating mobile unit The transition from the 

7 wait for alert state S4 to the tone and announce state S8 is along transition path T12. 

8 This transition occurs for two possible reasons. First, the transition may be based on a 

9 time out waiting for the alerting indication. The called party is cleared from the call 

10 and the mobile customer is connected to an announcement or tone. The CPM 414 

1 1 sends a CLEAR_CALL message to the called party. Second, the transition may be 

12 based on receiving a disconnect from the called party with "user busy." The 

13 originating mobile unit is sent an announcement and the called party is released from 

14 the call. The CPM 414 receives a C ALLJDIS CONNECTED message from the called 

15 party and sends a CLEAR_CALL message to the called party. Finally, the transition 

16 from the wait for alert state S4 to the wait for call cleared state S9 occurs along 

17 transition path T13 if the originating mobile customer disconnects from the call before 

18 the CPM 414 receives the alerting indication from the called party. Clearing both 

19 parties is initiated. The CALL^DISCONNECTED message is received from the 

20 originating mobile unit. The CPM 414 sends a CUEAR_CALL message to both 

21 parties. 

22 The state machine 600 may transition from the wait for connect state S5 to the 

23 voice state S6 along transition path T14 based on receiving connect indication from 

24 the called party. The connect indication is passed to the mobile customer. The CPM 

25 414 received a CAIX_CONNECTED message from the called party and sends a 

26 CONNECT_CALL message to the originating mobile unit. Transition from the wait 

27 for connect state S5 to the tone and announce state S8 occurs when a time out occurs 

28 waiting for the connect. The called party is cleared from the call and the mobile 

29 customer is connected to a tone or announcement. The CPM 414 sends a 
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1 CLEAR_CALL message to the called party. Transition from the wait for connect 

2 state S5 to the wait for call cleared state S9 occurs along transition path T 16 if the 

3 originating mobile subscriber disconnects from the call before the CPM 414 receives 

4 the connect indication from the called party. Clearing both parties is initiated. The 

5 CPM 414 receives a CALLJDIS CONNECT message from the originating mobile unit 

6 and sends a CLEAR_CALL message to both parties. 

7 The state machine 600 transitions from the voice state S6 to the wait for called 

8 clear state S9 along transition path T17 based on receiving a disconnect indication 

9 from either party. Call clearing is initiated for both parties on the call. A 

10 CALL_DISCONNECTED message is received from one of the parties. The CPM 

L 1 414 sends a CLEAR_CALL message to both parties. Transition from the voice state 

L2 S6 to the wait for hand off confirm state S7 occurs along transition path T18 based on 

13 receiving a hand off request from the HOP 416 subsystem and having a B-channel to 

14 allocate to the target BTS for the hand off. The CPM 414 receives a HANDJ3FF 

15 request from the HOP 416 and sends a MAKE_CALL message with a hand off 

16 indicating to establish the target channel. Finally, the voice state S6 transitions back 

17 to the voice state S6 along transition path T19 based on receiving a hand off request 

1 8 and not having a B-channel available to the BTS. 

19 The state machine 600 transitions from the wait for hand off confirm state S7 

20 to the voice state S6 along transition path T20 based on three possible events. First, 

11 the CPM 414 receives a hand off confirmation from the serving BTS. This indicates 

22 the mobile unit has confirmed the hand off and is in transition to the target BTS. The 

23 voice connection is switched to the target BTS at this point. The CPM 414 receives a 

24 HAND_OFF_CONFIRM message and sends a CLEAR_CALL to the old serving 

25 channel. The voice path in connected to silence until the CALL_CONNECTED 

26 message is received on the target channel. Second, the CPM 414 receives a hand off 

27 confirmation with a negative indication (failed). This indicates that the mobile unit is 

28 not going to the target channel. The CPM 414 starts a disconnect sequence to release 

29 the target channel. The CPM 414 then sends a CLEAR_CALL message to the target 
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channel. Third, the CPM 414 receives a failure on the channel setup with the target 
BTS. The transition to the voice state S6 occurs and the CPM 414 initiates or 
continues with the disconnect sequence with the target BTS channel. The CPM 414 
sends a CLEAR_CALL message to the target channel. Transition from the wait for 
confirm state S7 to the wait for call cleared state S9 occurs along transition path T21 
based on receiving a disconnect from either party while a target BTS channel is being 
established for the hand off. The CPM 414 initiates clearing all resources and 
transition. The CPM 414 receives a C ALL_DIS CONNECTED message and sends a 
CLEAR CAT J, message to the parties. 

The state machine 600 transitions from the tone and announce state S8 to the 
wait for call clear state S9 along transition path T22 based on the originating mobile 
unit disconnect indication being received from the CPM 414. This can occur as a 
result of a time out after the tone or an announcement is played and a disconnect is not 
received. In this case, the CPM 414 initiates the disconnect with the mobile customer. 
The CPM 414 initiates the disconnect with the mobile customer. The CPM 414 either 
receives a CALL_DISCONNECTED message and sends a CLEAR_CAUL message 
or the CPM 414 receives a time out and sends a CLEAR_CALL message. 

The state machine 600 transitions from the wait for call cleared state S9 to the 
idle state S 1 along transition path T23 based on both parties confirming they are 
cleared from the call. In cases where there is no other party involved in the call, the 
confirmation of the clearing of the party is implied by the fact that the cell never 
existed. This transition takes place when the call is completely cleared. The CPM 
414 receives a CALL_CLEARED message from the originating mobile unit. 

Figure 24 is a state machine 601 for PSTN originated call processing. In the 
state machine 601, the wait for UUI state S2 and the wait for handoff confirm state S7 
are not allowed states. The state machine 601 transitions from the idle state SI to the 
wait for page response state S3 along transition path T24 based on determining the 
need to page the mobile customer. The CPM 414 sends a PAGE_MOBILE message 
to the PAG thread 435. Transition from the idle state S 1 to the wait for alert state S4 
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1 occurs along transition path T25 based on determining that the mobile customer is 

2 located on another system and the aircore platform 200 has received a routing number 

3 to call the current serving switch. The CPM 414 sends a MAKE_CALL message 

4 using the TLDN (MSRN GSM). The transition from the idle state 5 1 to the wait for 

5 alert state 54 can also occur under a forwarding condition of the original destination 

6 number. Transition from the idle state SI to the tone and announce state S8 occurs 

7 along transition path T26 if the called number received from the originating PSTN 

8 party fails to translate properly or if there is a restriction on the called mobile unit In 

9 this case the originating PSTN party is connected to a tone or announcement. This 

10 transition could also occur by the CPM 414 receiving a PAGE_RESPONSE message 

1 1 with a time out indication. 

12 The state machine 601 transitions from the wait for page response state S3 to 

13 the wait for alert state S4 along transition path T27 based on receiving a 

14 PAGE_RESPONSE message. The CPM 414 sends a MAKE_CALL message and 

15 proceeds with the ISDN state machine. Transition from the page response state S3 to 

16 the tone and announce state S8 occurs along transition path T28 based on receiving a 

17 time out for a page response (i.e., PAGE_RESPONSE message received by the CPM 

18 414 with a time out indication). The CPM 414 provides a time out announcement or 

19 tone to the calling party. Transition from the wait for page response state S3 to the 

20 wait for call cleared state S9 occurs along transition path T29 based on receiving a 

21 disconnect from the originating PSTN party. The CPM 414 receives a 

22 CALL.DISCONNECTED message and sends a CLEAR_CALL message. The PAG 

23 thread 435 will time out and clear the page request data for the call. 

24 The state machine 601 transitions from the wait for alert state S4 to the wait 

25 for connect state S5 along transition path T30 based on receiving an alerting 

26 indication from the called party. The alerting indication is passed to the PSTN side of 

27 the call. The CPM 414 received a CAT J ALERTING message from the called party 

28 and sends an ALERT_CALL message to the originating PSTN party. Transition from 

29 the wait for alert state S4 to the voice state S6 occurs along transition path T3 1 based 



-35- 



BNSDOCID: < WO 0O46938A 1 J A> 



WO 00/46938 



PCT/US00/02797 



on receiving a connect indication from the called party. The protocol allows reception 
of the connection without receiving alerting. The CPM 414 receives a 
CALL_CONNECTED message from the called party and sends a CONNECT_CALL 
to the originating PSTN party. Transition from the wait for alert state S4 to the tone 
and announce state S8 occurs along transition path T32 for two possible reasons. 
First, transition may be based on a time out waiting for the alerting indication. The 
called party is cleared from the call and the PSTN party is connected to an 
announcement or tone. The CPM 414 sends a CLEAR_CALL message to the called 
party. Second, transition may be based on receiving a disconnect from the called party 
with **user busy." The originating PSTN party is sent an announcement and the called 
party is released from the call. The CPM 414 receives a C ALL_DIS CONNECTED 
message from the called party and sends a CLEAR CALL message to the called party. 
Transition from the wait for alert state S4 to the wait for call cleared state S9 occurs 
transition path T33 if the originating PSTN party disconnects from the call before the 
CPM 414 receives the alerting indication from the called party. Clearing of both 
parties is initiated. The CPM 414 receives a CALL_DISCONNECTED message from 
the originating PSTN party and sends a CLEAR_CALL message to both parties. 

The state machine 601 transitions from the wait for connect state S5 to the 
voice state S6 along transition path T34 based on receiving connect indication from 
the called party. The connect indication is passed to the PSTN party. The CPM 414 
receives the call connected message from the called party and sends the 
CONNECT_CALL message to the originating PSTN party. Transition from the wait 
for connect state S5 to the tone and announce state S8 occurs along transition path 
T35 when a time out occurs waiting for the connect. The called party is cleared from 
the call and the PSTN party is connected to a tone or announcement. The CPM 414 
sends a CLEAR_CALL message to the called party. Finally, transition from the wait 
for connect state S5 to the wait for call cleared state S9 occurs along transition path 
T36 if the originating PSTN party disconnects from the call before the CPM 414 
receives the connect indication from the called party. Clearing both parties is 
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1 initiated. The CPM 414 receives a CAIXJDISCONNECTED message from the 

2 originating PSTN party and sends the CLEAR_CALL message to both parties. 

3 The state machine 601 transitions from the voice state S6 to the wait for call 

4 cleared state S9 along transition path T37 based on receiving a disconnect indication 

5 from either party. Call clearing is initiated for both parties. The CPM 414 receives 

6 the CALL_DISCONNECTED message from one of the parties. The CPM 414 then 

7 sends the CLEAR_CALL message to both parties. 

8 The state machines 601 transitions from the tone and announce state S8 to the 

9 wait for call cleared state S9 along transition path T38 based on the originating mobile 

10 unit disconnect indication being received from the CPM 414. This can also occur as a 

1 1 result of a time out after the tone or announcement is played and a disconnect is not 

12 received. In this case, the CPM 414 initiates the disconnect with the mobile customer. 

13 The CPM 414 either receives a CALL^DISCONNECTED message and sends a 

14 CLEAR_CALL message or the CPM 414 receives a time out and sends the 

15 CLEAR__CALL message. 

16 The state machine 601 transitions from the wait for call cleared state S9 to the 

17 idle state S 1 along transition path T39 based on both parties confirming they are 

18 cleared from the call. In cases where there is no other party involved in the call the 

19 confirmation of the clearing of the party is implied by the fact that it never existed. 

20 Transition takes place when the call is completely cleared. The CPM 414 receives the 

21 CALL_CLEARED message from the originating mobile unit. 

22 Figure 25 shows a state machine 602 for a mobile terminated call processing. 

23 As shown in Figure 25, the states wait for UUI S2, wait for page response S3 and tone 

24 and announce S8 are not used in a mobile terminated call processing scenario. The 

25 state machine 602 transitions from the idle state S 1 to the wait for alert state S4 along 

26 transition path T40 based on reception of a valid PAGE_RESPONSE message. The 

27 CPM 414 sends a MAKECALL message to the terminating mobile unit. The idle 

28 state S 1 returns to the idle state S 1 along transition path T41 based on a page time out, 
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1 or failure in routing. The calling party is sent to an announcement or the call is 

2 forwarded based on the customer's feature profile. 

3 State machine 602 transitions from the wait for alert state S4 to the wait for 

4 connect state S5 along transition path T42 based on receiving an alerting indication 

5 from the terminating mobile customer. The alerting indication is passed to the calling 

6 party's side of the call. The CPM 414 receives a CALL.ALERTING message and 

7 sends a ALERT^CALL message to the calling party. Transition from the wait for alert 

8 state S4 to the voice state S6 occurs along transition path T43 based on receiving a 

9 connect indication from the called mobile unit. The protocol allows receipt of a 

10 receive connect message without receiving alerting. The CPM 414 receives a CALL_ 

1 1 CONNECTED message from the called party and sends a CONNECT_CALL 

12 message to the calling party. Transition from the wait for alert state S4 to the wait for 

13 call cleared state S9 occurs along transition path T44 if the calling party disconnects 

14 from the call before the CPM 414 receives the alerting indication from the mobile 

15 customer. Clearing both parties is initiated. The CPM 414 receives a CALL 

16 DISCONNECTED message from the calling party and sends a CLEARCALL 

17 message to both parties. In addition, in time out cases where the calling party is sent 

18 to an announcement, the called mobile unit will receive a CLEAR_CALL message 

19 from the CPM 414 and make the transition. 

20 The state machine 602 transitions from the wait for connect state S5 to the 

21 voice state S6 along transition path T45 based on receiving a connect indication from 

22 the called mobile customer. The connect indication is passed to the calling party. The 

23 CPM 414 receives a CAIJL CONNECTED message and sends a CONNECT.CALL 

24 message to the calling party. Transition from the wait for connect state S5 to the wait 

25 for call clear state S9 occurs along transition path T46 that the calling party 

26 disconnects from the call before the CPM 414 receives the connect indication from 

27 the mobile customer. Clearing both parties is initiated. The CPM 414 receives a 

28 CAIXJDISCONNECTED message from the calling party. The CPM 414 then sends a 

29 CLEARCALL message to both parties. In addition, in time out cases where the 
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1 calling party is sent to an announcement, the called mobile unit will receive a 

2 CLEAR_CALL message from the CPM 414 and make the transition. 

3 The state machine 602 transitions from the voice state S6 to the wait for call 

4 cleared state S9 along transition path T47 based on receiving a disconnect indication 

5 from either party. Call clearing is initiated for both parties in the call. The CPM 414 

6 receives a CALL.DISCONNECTED message from one of the parties and sends a 

7 CLEARCALL message to both parties. Transition from the voice state S6 to the wait 

8 for hand off confirm state S7 occurs along transition path T48 based on receiving a 

9 hand off request from the HOP subsystem 416 and having a B-channel to allocate to 

10 the target BTS for the hand off. The CPM 414 receives a hand off request message 

1 1 from the HOP 416 and sends a MAKECALL message with a hand off indication to 

12 establish the target channel. Transition from the voice state S6 back to the voice state 

13 S6 occurs along transition path T49 based on receiving a hand off request and not 

14 having a B-channel available to the BTS. 

15 The state machine 602 transitions from the wait for hand off confirm state S7 

16 to the voice state S6 along transition path T50 in one of three situations. First, the 

17 CPM 414 receives a hand off confirmation from the serving BTS. This indicates the 

1 8 mobile unit has confirmed the hand off and is transitioning to the target BTS. Voice 

19 connection is switched to the target BTS at this point. The CPM 414 receives the r 

20 HANDOFFCONFIRM message and sends the CLEAR_CALL message to the old 

21 serving channel. The voice path is connected to silence until the CAlX. 

22 CONNECTED message is received on the target channel. Second, the CPM 414 

23 receives a hand off confirmation with a negative indication (failed). This indicates 

24 that the mobile unit is not going to the target channel. A disconnect sequence to 

25 release the target channel is started and the CPM 414 sends a CLEAR_CALL message 

26 to the target channel. Third, the CPM 414 receives a failure of the channel set up with 

27 the target BTS. Transition to the voice state S6 in initiation or continuation of the 

28 disconnect sequence with the target BTS channel begins. The CPM 414 sends a 

29 CLEARCALL message to the target channel. Transition from the hand off confirm 
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1 state S7 to the wait for call cleared state S9 occurs along transition path T5 1 based on 

2 receiving a disconnect from either party while a target BTS channel is being 

3 established for the hand off. The CPM 414 initiates clearing all resources and 

4 transition. The CPM 4 14 receives a CALL DISCONNECTED message and sends a 

5 CLEAR_CALL message to all parties. 

6 The state machine 602 transitions from the wait for call cleared state S9 to the 

7 idle state S 1 along transition path T52 based on both parties confirming they are 

8 cleared from the call. In cases where there is no other party involved in the call, the 

9 confirmation of the clearing of this party is implied by the fact that a call never 

10 existed. This transition takes place when the call is completely cleared. The CPM 

1 1 414 receives a CALLCLEARED message from the originating mobile unit. 

12 The aircore platform 200 uses a common facility state machine for tracking the 

13 states and conditions of external connections or trunks. Two portions of the state are 

14 tracked. Each facility has a near end and a far end state. The near end state represents 

15 the internal aircore state for the facility. The far end state represents the state of the 

16 facility as reported by the connected system. This state machine tracking applies to all 

17 aircore interfaces mcluding traffic channels and signaling channels. Like call 

18 processing, these maintenance procedures are generic in the aircore platform 200 

19 ^ regardless of the interface. 

20 Figure 26 is a aircore near end facility maintenance state machine 604. The 

21 state machine 604 includes the states not configured (S 10), blocked (S 1 1), unblocked 

22 pending (S 12), unblocked (S 13), call processing (S 14), blocked pending (S 15), and 

23 maintenance (SI 6). 

24 Figure 26 also shows the transitions between the states of the state machine 

25 604. The state machine 604 transitions from the state not configured S 10 to the 

26 blocked state S 1 1 along transition path T60 when a facility is added to the 

27 configuration and is enabled. 

28 The state machine 604 transitions from the blocked state S 1 1 to the unblocked 

29 pending state S12 over transition path T61 when either operator initiated or automatic 
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1 recovery occurs which requests that the destination device handler bring the requested 

2 facility to an unblocked (in service) state. Transition from the blocked state S 1 1 to the 

3 maintenance state S 16 occurs along transition T62 when the facility is taken to a 

4 maintenance state to perform a maintenance or test operation. This transition is based 

5 on an operator action. Transition from the blocked state S 1 1 to the not configured 

6 state S 10 occurs along transition path T63 when the facility is disabled and/or 

7 removed from the system configuration. 

8 The state machine 604 transitions from the unblocked pending state S 12 to the 

9 unblocked state S 13 over transition path T64 when a maintenance action is confirmed 

10 by the device handler. The facility is now in service. Transition from the unblocked 

1 1 pending state S 12 to the blocked pending state S 15 occurs over transition path T65 

12 when a maintenance action is denied by the device handler or aborted by an operator 

13 action. 

14 The state machine 604 transitions from the unblocked state S 13 to the call 

15 processing state S 14 along transition path T66 when the facility is allocated and will 

16 be used for call processing. Transition from the unblocked state S 13 to the blocked 

17 pending state S 15 occurs along transition path T67 when either operator initiated or 

18 automatic maintenance action from the device handler. Transition also occurs based 

19 on other internal action requests that the destination device handler bring the 

20 requested facility to a blocked (off-line) state. 

21 The state machine 604 transitions from the call processing state S14 to the 

22 unblocked state S 13 over transition path T66 when the facility is released from being 

23 used in call processing. Transition from the call processing state S 14 to the blocked 

24 pending state S 15 occurs over transition path T69 when a maintenance action is either 

25 operator initiated or automatic from the device handler or other internal action 

26 requests that the device destination handler bring the requested facility to a blocked 

27 (off-line) state. 

28 The state machine 604 transitions from the blocked pending state S 15 to the 

29 blocked state S 1 1 over transition path T70 when a maintenance action to take facility 
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1 off-line is confirmed by the device handler. In a case where the device handler does 

2 not respond, the state may be reached by default of no response. 

3 The state machine 604 transitions from the maintenance state S 16 to the 

4 blocked state S 1 1 over transition path T71 when the maintenance action on the facility 

5 is completed. Operator action is required to transition the state back to the blocked 

6 state SI 1. 

7 In addition to monitoring the near end state of the system facilities, the aircore 

8 platform 200 also maintains the far end state of facilities where applicable. The far 

9 end state represents the status of a facility at the connected system side. The far end 

10 state and near end state are used together to determine the overall operational state. 

1 1 Figure 27 shows the aircore far end facility maintenance state machine 605. In 

12 Figure 27, the states are not configured (S 17), blocked (S 18), unblocked (S 19), and 

13 unknown (S20). 

14 The state machine 605 transitions from the not configured state S 17 to the 

15 blocked state S 18 along transition path T80 when a facility is added to the 

16 configuration and enabled. 

17 The state machine 605 transitions from the blocked state S 18 to the unblocked 

18 state S19 over transition path T81 when an unblocking request is received from the far 

19 end. Confirmation is then sent back with an unblocking acknowledgment message. 

20 Transition from the blocked state S 1 8 to the unknown state S20 occurs over transition 

21 path T82 when a discrepancy has been detected between the state reported by the far 

22 end and the stored far end state for the facility in aircore platform 200. The blocked 

23 state S 1 8 transitions to the not configured state S 17 over transition path T83 when the 

24 facility is disabled and/or removed from the system configuration. 

25 The state machine 605 transitions from the unblocked state S 19 to the blocked 

26 state S 18 over transition path T84 when a blocking request message is received from 

27 the far end. Confirmation is sent back with the blocking acknowledgment message. 

28 Transition from the unblocked state S 19 to the unknown state S20 occurs over 
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1 transition path T85 when a discrepancy has been detected between the state reported 

2 by the far end and the stored far end state for the facility in the aircore platform 200. 

3 The state machine 605 transitions from the unknown state S20 to the blocked 

4 state S 18 over transition path T86 when the far end reports the state of the facility is 

5 blocked. Transition from the unknown state S20 to the unblocked state S 19 occurs 

6 over transition path T87 when the far end reports the state of the facility is unblocked. 

7 Hand off processing occurs when an active mobile unit transitions from a 

8 wireless region supported by one base station to a wireless region supported by a 

9 second base station- Hand off processing may also occur as a mobile unit transitions 

10 from one cell site within a wireless region to another sell site. 

1 1 Figure 28 shows an aircore wireless environment 106 in which the aircore 

12 platform 200 functions as a mobile switching center (MSC). There are many different 

13 protocol scenarios that are possible for hand off processing in the aircore environment 

14 106, including ISDN PRI+ with an AMPS base station, DHD-based (AMPS) base 

15 station, IS-634 AMPS, IS-634 TDMA, IS-634 CDMA, GSM, K-41 Revision B, IS-41 

16 Revision C and GSM mobile application part (MAP). In addition, the processing 

17 design of the aircore platform 200 retains the flexibility to easily adapt to other hand 

18 off protocols. Finally, the aircore platform 200 may receive hand off requests from 

19 multi-protocol mobile units. 

20 In Figure 28, base station controllers (BSCs) 105^ and 105 2 and base 

21 transceiver stations (BTSs), are shown connected to the aircore platform 200 via 

22 signal lines 485 and 495, respectively. The BSC 105j has an associated wireless 

23 region 480 that includes BTSs 481, 482 and 483. The BSC 105 2 has an associated 

24 wireless region 490 with BTSs 491, 492 and 493. The mobile unit 1 12 is active in the 

25 wireless region 480 at point A and communicates with a land-line phone 114 via 

26 PSTN 120, the aircore platform 200, the BSC 105 j and the BTS 481. 

27 In the above description, the BTS receives a call from a mobile unit. The 

28 mobile unit may be a mobile telephone or a computer with a wireless modem, for 
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1 example. In addition, the BSC/BTS may be replaced in some scenarios with a BSS or 

2 any other base station configuration. 

3 During the course of a call, the mobile unit 1 12 transitions from point A in 

4 wireless region 480 to point B in wireless region 490. As a result of this transition, 

5 the BTS 105, detects that the signal level of the cell has dropped below the minimum 

6 to continue the call on the cuiTent channel. The BSC I05 x notifies the aircore 

7 platform 200, which begins hand off processing to establish a new cell site using the 

8 BSC 105 2 . When the new cell site is established, the aircore platform 200 tears down 

9 the previous link, thereby freeing up resources for other wireless customers. 

10 In the scenario described above, the BSC 105, and 105 2 are both associated 

1 1 with the aircore platform 200 and certain hand off processing functions such as 

12 strength measurements are performed by the aircore platform 200. In a scenario 

13 involving a base transceiver station coupled to another mobile switching center, the 

14 base transceiver stations may perform these hand off processing functions. 

15 As with other processing functions, the software architecture 300 of the aircore 

16 platform 200 is designed to use, as much as possible, generic processing for mobile 

17 unit hand offs. Thus, communications from the mobile units operating according to 

18 different protocols, e.g., GSM, TDMA, CDMA and AMPS are handled in a generic 

19 fashion, except where specific differences are required. The message flows associated 

20 with these protocols will be described later. 

21 Referring to Figure 10, once a base station detects that the signal level has 

22 either dropped below the minimum, or exceeded the maximum, to continue the call on 

23 the current channel, hand off processing begins. Measurements are taken of bordering 

24 systems to determine the best candidate system, or target base station. The HOP 416 

25 is involved in this for analog protocols and some inter-system hand offs. Otherwise, 

26 the step may be handled directly between the base station and the mobile unit. For 

27 digital protocols, the base station sends the target information to the HOP 416 for 

28 transmission to the CPM 414. For ISDN PRI + and DHD based analog protocols, the 

29 HOP 416 determines the appropriate target for the hand off. Next, the CPM 414 is 
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1 notified via the HOP 416 of the required hand off and begins establishing a voice 

2 circuit to the target system. Once confirmed, the CPM 414 sends the hand off 

3 command to the current serving base station. This information is passed to the mobile 

4 unit The mobile unit confirms the reception of the target information and switches to 

5 the new frequence and voice path. Upon arrival at the new frequency, the new serving 

6 base station passes the confirmation to the CPM 414. The CPM 414 switches the 

7 voice path during this process to the new channel and tears down the voice path to the 

8 old serving system. 

9 As noted above, the HOP 416 preprocess is limited. After the hand off is in 

10 progress, the HOP 416 is no longer involved. Call processing uses the information 

1 1 provided by the HOP 416 to establish appropriate resources to complete the hand off. 

12 Call processing is responsible for the control of the remaining portion of the hand off. 

13 For ISDN PRI+ protocol hand offs, a message is sent to the aircore platform 

14 200 from a base station to indicate that a mobile unit requires a hand off. The 

15 message specifies a protocol discriminator, a call reference (whose value is assigned 

16 in a SETUP message), a message type and a user identification. The aircore platform 

17 200 in turn sends a hand off message request to the base station to request the base 

18 station measure a specific frequency. Finally, the base station sends a message to the 

19 aircore platform 200 to report the measured strength of the signal recorded on the base 

20 station. 

21 ISDN PRI+ processing requires that the HOP 416 accept a hand off request 

22 from the DHI 503. Appropriate hand off related information, including call reference 

23 and RF channel, for example, is stored in the air core platform 200. The call reference 

24 is a number that is retrieved from the device handler thread data that is initially stored 

25 when call setup takes place. The RF channel is also retrieved from the device handler 

26 thread data. The air core platform 200 then sends measurement requests to 

27 appropriate boarder cells, sets a measurement request timer, and processes responses 

28 from the base station. 
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1 For DHD based protocol hand offs, the HOP 416 accepts a hand off request 

2 from one of the device handlers in the aircore platform 200. The appropriate hand off 

3 related information, including the call reference and RF channel, for example, are 

4 stored. The aircore platform 200 allocates a voice channel and sends measurement 

5 requests (SCANs) to the appropriate border cells, sets a measurement timer, and 

6 processes responses received from the base stations. For base stations not chosen for 

7 hand off, the aircore platform 200 initiates a channel release. If a suitable target cell is 

8 determined, the HOP 416 send the information to the CPM 414 for hand off. 

9 For DHD based protocol hand off processing, a voice channel is assigned to 

10 each base station when the measurement process takes place. For example, if three 

1 1 base stations border the current wireless system and a measurement is to be taken, a 

12 voice channel is explicitly reserved in each base station. When the target base station 

13 is chosen, the voice channels in the other base stations must be released. To 

14 accomplish this release, the device handlers will allocate and release the appropriate 

15 channels for the measurements in accordance with commands sent by the HOP 416. 

16 If an allocation fails or there are no channels available in a base station, the device 

17 handlers send allocation failure events to the HOP 416, and the HOP 416 removes the 

18 base station from the candidate list for the current hand off. 

1 9 IS-634 analog hand off processing requires the HOP 4 1 6 to send a 

20 measurement request to the AIM 430. The measurement request is then sent to 

21 appropriate border cells. The measurement requests are sent back to the requesting 

22 base station, and the information is forwarded to the HOP 416, for determination of 

23 the target cell. 

24 The strength measurement message is transferred to cells that are listed in a 

25 Cell Identifier List parameter that is sent in the message. The HOP 416 stores the 

26 reference number against the requesting base station so the return messages find the 

27 correct base station. The reference number is timed in accordance with a base station 

28 timer for measurement collection. Responses received after timer expiration are 

29 discarded. 

-46- 

BNSDOCID: <WO 0046938A1 JA> 



WO 00/46938 



PCT/USU0/02797 



1 IS-634 TDMA hand off processing requires that the HOP 416 determine, 

2 based on information received from the base station in a hand off required message, 

3 the appropriate candidate cell. The HOP 416 then sends the appropriate information 

4 to the CPM 414. If the HOP 416 does not find a suitable target cell, the hand off is 

5 aborted. 

6 IS-634 CDMA hand off processing requires the that HOP 416 determine an 

7 appropriate target cell, based on information received by the HOP 416 from the base 

8 station. The HOP 416 aborts the hand off if a suitable target cell is not determined. 

9 GSM hand off processing requires that the HOP 416 use information received 

10 from the base station in the hand off required message to determine appropriate target 

1 1 cells. Once again, the HOP 416 aborts the hand off if a suitable target cell is not 

12 located. 

13 For hand off processing from a multiple protocol base station, the message 

14 flows to the HOP 416 indicate the appropriate protocol of the mobile unit. For 

15 intersystem hand offs, messages related to the intersystem hand off preprocessing are 

16 sent from the HOP 416 to the IMH 432 and from the IMH 432. The border cell for 

17 measurement may be reached in the same manner as sending a message to multiple 

18 cell sites, except that the messages are intersystem. Therefore, the messages are sent 

19 to the IMH 432, or are received from the IMH 432 instead of the AIM 430 base 

20 station threads, DUE 503 or DHD 50 1 . 

21 Each cell supporting hand off in the aircore system 106 must have an 

22 associated list of border cells that are contacted in the event of a hand off attempt. 

23 These cells may have an identity that ties the cells to a link. These cells also have a 

24 protocol that the HOP 416 and the CPM 414 can use for determining message 

25 destination, supported protocols, and associated trunk groups, all of which may be 

26 used for new voice circuit allocations. 

27 Because the aircore platform 200 is capable of processing a number of 

28 different protocol messages, some mechanism must be provided to determine the 

29 correct protocol. For messages received from a single-protocol BSS, the aircore 
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platform 200 determines the correct protocol by reference to the protocol established 
for that particular BSS. The BSS is then associated with a signaling link mechanism 
that connects the BSS to the MSC 210. The link may be a SS-7 base, TCP/IP, LAPD, 
CAS and ATM, for example. The MSC 210 associates the type of protocol supplied 
by the BSS to any incoming messages received from the BSS. The actual protocol for 
the base station is determined when the link to the BTS or BSS is brought into service. 
One example is when the DH-7 510 spawns a thread connecting the BSS to the MSC 
210. 

To ensure signaling messages used with the aircore platform 200 perform the 
same generic function across protocols, tables of messages may be used for different 
aircore platform functions. The table that follows shows some of the messages used 
for call processing in the aircore platform 200, and the accompanying messages 
according to specific protocols. 



Internal AireCore Call 
Processing Event 


GSM 
(Euro and 
US) 


IS-634 
CDMA 


IS-634 
TDMA 


IS-634 
AMPS 


CPMJPAG_PAGE_MOBILE 


Page Request 


Page Request 


Page Request 


Page Request 


PAG_CPM_PAGE_RESPONSE 


Page Response 


Page Response 


Page Response 


Page Response 


MAKE_CALL 


Setup 


Setup 


Setup 




CALL.RECEIVED 


Setup 


Setup 


Setup 


Setup 


ROUTE_CALL 


Assignment 
Complete 


Assignment 
Complete 


Assignment 
Complete 


Assignment 
Complete 


ALERT.CALL 


Alerting 


Alerting 


Alerting 


Alerting 


CALL_ ALERTING 


Alerting 


Alerting 


Alerting 


Alerting 


CONNECILCALL 


Connect 


Connect 


Connect 




CALL_CONNECIED 


Connect 


Connect 


Connect 




CLEAR.CALL 


Disconnect 


Disconnect 


Disconnect 




CALL_DIS CONNECTED 


Disconnect 


Release 


Release 




CLEAR_CALL 


Release 


Release/Release 
Complete 


Release/Release 
Complete 


Release/Release 


CALL__CLEARED 


Release 
Complete 


Release 
Complete 


Release 
Complete 


Release 
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1 Calls may fall into one of several scenarios, including mobile originated (a 

2 mobile unit originates the call), mobile terminated (a call to a mobile unit) and PSTN 

3 originated, for example. Mobile originated calls may be received at the MSC and may 

4 be originated at another wireless system (intersystem). Mobile originated calls may 

5 also be received at a BTS and may then be passed to the MSC. 

6 The aircore platform 200 initiates a location update sequence to register a 

7 mobile unit with the aircore platform 200. A customer profile is retrieved from the 

8 VLR 422 or HLR 424 as necessary. Once a customer profile is retrieved, the 

9 procedures for call setup across the protocols is generic. The use of a standard 

10 internal set of procedures allows the call processing of the aircore platform 200 to be 

1 1 independent of the type of interface used when establishing the call. The events that 

12 are specific to a particular protocol are handled by individual components of the AIM 

13 430. A CALL.RECEIVED message announces arrival of an incoming call to the 

14 CPM 414. When this message is sent, the customer profile is included as well as the 

15 selected traffic channel. The CALL.RECEIVED message is sent based on proper 

16 profile retrieval, authentication and channel selection. A ROUTECALL message is 

17 sent to the CPM 414 as an indication that the call may be routed to the network since 

18 the traffic channel allocation to the originating mobile unit was successful. The 

19 ROUTECALL message is sent based on proper channel assignment for the call. An 

20 ALERT_CALL event is received from the CPM 414 as an indication that the far end of 

21 the call is in the alerting state. When this event is received, an alert message is sent to 

22 the mobile unit. A CONNECT.CALL event is received as an indication that the far 

23 end has connected the call. This indication is passed on to the mobile station in the 

24 connect message. The above four events are used between the CPM 414 and all other 

25 subsystems for call originations in the system. 

26 Mobile termination also uses a set of generic events and/or messages. 

27 However, mobile termination is more of a challenge than mobile origination, since the 

28 current operating mode of a subscriber is not known prior to querying the relative 
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1 databases. Similar to the mobile origination procedure and the location updating 

2 procedure, mobile termination is generic for all base station-type interfaces regardless 

3 of the protocol. The first query is to the HLR 424 via the IMH 432. Call processing 

4 sends an event to the IMH 432 requesting the current location of the customer and 

5 how to reach the customer. This request is sent without indication of the intrasystem 

6 protocol to use. The IMH 432 utilizes the MIN/MSISDN to HLR mapping table to 

7 determine a protocol and location of the HLR in the network. 

8 For an internal HLR, the event is built and sent to the HLR 424 for processing. 

9 The protocol indicator is set based on the mapping table and a search is performed to 

10 locate the customer profile in the HLR database. If the customer profile is not found, 

1 1 the HLR 424 can optionally query the opposite side of the database in the case where 

12 the phone supports multiple modes and protocols. Once found, the VLR 422 is 

13 contacted (if not local) via standard procedures, such as ROUTE_REQUEST or 

14 PROVIDE_ROAMING.NUMBER. 

15 For call tear down, the aircore platform 200 is based on the ISDN model for 

16 call release. This scenario is a three message sequence beginning with the requesting 

17 interface presenting notification of a disconnect. The notification is followed with a 

1 8 two event exchange with all involved subsystems for the call to command the release 

19 of the call and a return message to confirm the release. Low level processing in the 

20 aircore platform 200 ranges from changing the state of supervision bits to a two or 

21 three message exchange. 

22 Figure 29a shows the basic components of the aircore platform 200 that are 

23 involved in call processing in the above scenarios. As shown in Figure 29a, calls to 

24 the aircore platform 200 may be received at a device handler such as the DH-7 510. 

25 The device handler DH-7 510 may communicate with the IMH 432 and the AMH 

26 43 1. The VLR 422 and the HLR 424 and AC/AuC (not shown) may be addressed by 

27 the IMH 432 to retrieve customer-specific data and to perform other functions, 

28 including customer location, for example. The CPM 414 communicates with the ARS 

29 434, the IMH 432 and the PAG 435. 
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1 The components shown in Figure 29a communicate via a set of generic 

2 messages. These messages indicate receipt of a call, authentication, call routing and 

3 call connection, for example. 

4 To ensure proper tracking of a call and the call's processing, whenever a call 

5 comes into the aircore platform 200, the AMH 43 1 receives a notification from the 

6 DH-7 510. The AMH 43 1 accesses the decoder thread to decode the incoming 

7 message and to determine the appropriate action. If the message is the first message 

8 associated with a call, the AMH 43 1 allocates an area in the common memory 439, 

9 with an index to that area. For the duration of the call processing and the call, the 

10 designated area will be used as needed during the transaction processing. For 

1 1 example, the designated area includes the customer identification number and the base 

12 station identification. 

13 The AMH 43 1 can spawn threads unique to base station protocols such as 

14 GSM or RDMA, TDMA, or AMPS. The AMH 43 1 may also spawn different threads 

15 depending on the manufacturer of a mobile unit. 

16 The IMH 432 works in a fashion similar to that of the AMH 43 1 in that the 

17 IMH 432 spawns different threads, depending on the protocol required for the system 

18 (GSM or ES-41). When the IMH 432 deals with internal events, it shares the index 

1 9 and memory space used by the associated AMH 43 1 . The IMH 432 pulls the message 

20 from the memory space of the common memory 439 created by the AMH 43 1 , using 

21 the index created by the AMH 43 1 . 

22 The IMH 432 also processes events without the involvement of an AMH 431 

23 thread. For these situations, the index and memory area are allocated by the IMH 432 

24 thread. Memory and index allocation are coordinated within the AIM 430 subsystem. 

25 The ARS 434 communicates with the VLR 422 via the IMH 432 thread to 

26 retrieve the requisite information to authenticate the subscriber and determine the 

27 validity of the transaction. The processing of the ARS 434 thread is made generic. 

28 The PAG 435 thread tracks the outstanding page requests that are in process 

29 for the system. The PAG 435 thread receives incoming PAGE_MOBELE events from 
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1 the CPM 414 when a mobile unit is to be paged on the aircore system. The PAG 435 

2 thread determines the appropriate base station resources that should be sent the PAGE 

3 message. The PAGE_REQUEST message is then communicated to the appropriate 

4 AMH 431 threads for processing. In a multi-protocol environment, the decision on 

5 the base stations that receive the PAGE_REQUEST event is based on the last known 

6 technology that the mobile unit was operating on. If a mobile unit has GSM and 

7 CDMA capabilities, and the last activity for the mobile unit was on the GSM portion 

8 of the system, the PAG 435 thread will process this as a GSM based paging. If 

9 however, there is not a last known technology for the mobile unit, all technologies 

10 within the mobile unit's capabilities are paged. If the mobile unit referenced above did 

1 1 not have a last known technology, both the CDMA and the GSM based paging would 

12 take place. Once the PAGEJRESPONSE message is received, the AMH 43 1 thread 

13 decodes the message and sends the decoded data, via the common memory 439 to the 

14 PAG 435 thread where an association is made between the incoming 

15 PAGEJRESPONSE and the previous outgoing PAGE_REQUEST messages. Based 

16 on the responding base station, the appropriate technology can be determined. The 

17 determination of the proper protocol at this point is much like the determination used 

18 for mobile originated actions. The responding base station determines the protocol 

19 based on its capabilities that were known when the interface to the base station was 

20 brought into service. 

21 Call processing also uses a common reference scheme to track all events 

22 associated with a call. This scheme is illustrated in Figure 29b. Each call placed with 

23 the aircore platform 200 leads to creation of a session 490 with a session object header 

24 491. The session object header 491 is created based on an index number generated 

25 from the board, span, and channel used for the first party involved in the call. Board, 

26 span and channel is a reference created relative to the physical interface used for 

27 system access. The session 490 adds and removes call objects 492 t as dictated by the 

28 progression of the call. Each session 490 has a reference number for the session that 

29 is based on the originator's board span and channel. However, the session may also 
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1 be indexed by an index number of the board, span and channel of any of the parties 

2 involved in the session. As shown in Figure 29b, each party object has its own data 

3 related to the customer or the interface to which it is related. 

4 The authentication process may be initiated as a result of either a service 

5 request by a mobile unit or following the successful page of a mobile unit, but is 

6 performed primarily under the control of the VLR. The authentication process may be 

7 set up to be performed every time a mobile unit originates a call or when a call 

8 terminates at a mobile unit. Authentication may also take place whenever a location is 

9 updated for the mobile unit that is in a power on or an idle state. Finally, 

10 authentication may occur when a mobile unit registers by turning power on. 

1 1 When a mobile unit originates a request for service, the mobile unit sends a 

12 message to the MSC, including the IMSI, a mobile identification number (MIN), or a 

13 temporary mobile subscriber identification (TMSI). The MSC may use the IMSI, the 

14 MIN, or the TMSI as the primary identification for the mobile unit. The IMSI is a 

15 permanent number that is assigned to every mobile unit. The MIN is a permanent 

16 number assigned to a mobile unit in the case where an IMSI is not used. (MIN is used 

17 in older AMPS based mobile units). The TMSI is assigned to a mobile unit only after 

18 an authentication, and has only local significance. If the TMSI is not recognized from 

19 the mobile unit, then a request is made to use the IMSI to continue the authentication. 

20 Upon successful authentication, a new TMSI (if used) is assigned to the mobile unit 

21 for future system access. 

22 The authentication center is the source of data used in authentication. The 

23 authentication center does not store data for the customers. Instead, the authentication 

24 performs calculations using random numbers that are used in conjunction with data in 

25 the HLR to generate authentication data. When a customer first subscribes for 

26 service, the customer is assigned a secret key (Kj for GSM, A-key for CDMA, 

27 TDMA). The key and a random number supplied by the authentication are used by 

28 the authentication center to generate a result The data calculations also yield values 

29 used for encryption keys. Depending on the protocol (GSM or IS-41 based), the 
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1 authentication process can occur at different times during the establishment of 

2 communications between the mobile unit and the MSC 210. The similarities between 

3 the authentication procedures are found in the fact that they produce results that are 

4 used for both access verification and encryption. Although the security calculations 

5 the responsibility of the authentication center, the initiation of the actual 

6 collection/transmission of data and the comparison to determine the validity of the 

7 access is the responsibility of the ARS 434 thread 

8 When authentication is requested, the MSC sends the random number of the 

9 mobile unit. The mobile unit retrieves the from its initialization memory and 

10 calculates a signed response (SRES) and an encryption key K^. The mobile unit then 

1 1 stores the K. and sends the SRES to the MSC. The ARS 434 identifies that the SRES 

12 sent by the mobile unit matches the SRES calculated by the ARS 434. If the values 

13 match, the value of K,. stored in the mobile unit is assumed to be correct. This 

14 authentication process does not require that the encryption key or the initial key 

15 be transmitted over the air, thereby ensuring security for the encryption process. 

16 A* 1 example of the GSM authentication process is described with reference to 

17 Figure 29c. The authentication process starts with step SI 0. The process then moves 

18 to step S12 where a mobile unit sends a service request message to the aircore 

19 platform 200. The message includes the temporary mobile subscriber identification 

20 (TMSI). The process them moves to step S14. In step S14, the ARS 434 compares 

21 the TMSI sent from the mobile unit to the TMSI recorded in the VLR 422. If the ARS 

22 434 recognizes the TMSI, the process moves to step S20. Otherwise the process 

23 moves to step S 1 6. 

24 In step S 16, the ARS 434 requests the IMSI for the mobile unit from the VLR 

25 422. The process then proceeds to step S20. In step S20, the aircore platform 200 

26 sends a message to the mobile unit indicating that the mobile unit is recognized. The 

27 process then moves to step S24. 

28 In step S24, the mobile unit sends an authentication request message to the 

29 aircore platform 200. The process then moves to step S28. In step S28 5 the aircore 
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1 platform 200 sends a random number to the mobile unit and the authentication center 

2 platform 200 sends a random number to the mobile unit and the authentication center 

3 calculates a signed response (SRES) based on the random number. The process then 

4 moves to step S30. 

5 In step S30, the mobile unit, after receiving the random number, retrieves the 

6 case from its initialization memory and calculates the SRES and the encryption key 

7 K(.. The process then moves to step S34. In step S34, the mobile unit stores the 

8 encryption key K,. and sends the SRES to the aircore platform 200. The process then 

9 moves to step S38. In step S38, the ARS 434 compares the SRES calculated by the 

10 mobile unit with that calculated authentication center 200. If the two SRESs match, 

1 1 the process moves to step S44. Otherwise the process moves to step S40. In step S40, 

12 the aircore platform 200 sends a message to the mobile unit indicating that the 

13 authentication failed. 

14 In step S44, the ARS 434 completes the authentication process. The process 

15 then moves to step S48. In step S48, the ARS 434 determines if the mobile unit needs 

16 a TMSL If the mobile unit needs a TMSI, the process moves to step S50. In step S50, 

17 the ARS 434 assigns a TMSI to the mobile unit and stores the value of the TMSI in 

18 the VLR 422. The process then moves to step S60. In step S60, the authentication 

19 process ends and call processing continues. The message flows associated with a 

20 failed authentication are shown in Figure 58. 

21 The above-described authentication process is the GSM authentication 

22 procedure, which is one of several authentication procedures available to the MSC. 

23 Other authentication processes may vary according to the call processing protocol, for 

24 example. 

25 The operation of the aircore platform 200 in a multi-protocol wireless 

26 environment is explained below with reference to Figures 30-72. 

27 When the aircore platform 200 and base station controllers are first brought on 

28 line, they exchange messages to ensure that all circuits are properly aligned. Figure 30 

29 shows the reset and reset acknowledgment function when the base station controller is 
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1 started. In Figure 30 base station controller (BSC) 105 sends a reset message 620 to 

the device handler DH-7 5 10 to initiate the message sequence. The DH-7 5 10 

3 transfers the message to the AMH 43 1 using DH-7.AMH TRANSFER 62 1 . The 

4 AMH 43 1 then sends an AMH REC RESET 622 to the REC 402 to initiate the reset. 

5 The REC 402 returns a reset acknowledge to the BSC 105 using the 

6 RECAMHRESETACK 623, which is sent to the AMH 431. The AMH 431 

7 transfers the reset acknowledgment to the DH-7 510 using AMHJDH-7 TRANSFER 

8 624. The DH-7 510 then sends a RESET_ACK 625 to the BSC 105. The BSC 105 

9 then sends a BLOCKING or CIRCUIT .GROUP BLOCK 626 to the DH-7 510. The 
DH-7 510 sends a DH-7.AMH TRANSFER 627 to the AMH 431, which in turn sends 
an AHM.REC BLOCKING or AMH REC CIRCUIT GROUP .BLOCKING 628 to 
the REC 402. This process then continues until all the circuits are in the appropriate 

13 state on the side of the aircore platform 200. 

14 Figure 3 1 shows the reset and reset acknowledgment message flows for a base 
controller failure. The message flows are similar to those shown in Figure 30. 

Figure 32 shows the message flows for the start up of the aircore platform 200. 
17 Upon startup, the REC 402 sends a REC AMH RESET 640 to the AMH 43 1 . The 

AMH 431 transfers the reset message to the DH-7 510, using an AMH_DH7_ 
TRANSFER 641, and starts a T16 timer 644 using AMHTMR SETJTCMER (RESET) 

20 643. The reset signal (RESET 642) is then sent to the BSC 105. The BSC 105 

21 returns a RESET ACK 645 to the aircore platform 200 and the AMH 431 releases the 
T16 timer 644 using AMH_TMR_RLS TIMER (RESET) 647. The AMH 43 1 then 
passes the reset acknowledgment to the REC 402 using AMH.REC.RESET ACK 648. 
Finally, the BSC 105 indicates blocking or circuit group blocking by sending an 
appropriate message to the aircore platform 200. This process continues until all the 
circuits are in the appropriate state on the side of the aircore platform 200. 

Figure 33 shows the message flows for startup of the aircore platform 200 in 
28 the event of a circuit failure. 
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1 Figure 34 shows the message flows for startup of the aircore platform 200 in 

2 the event the T16 timer 644 times out before the BSC 105 returns a reset 

3 acknowledgment message to the aircore platform 200. 

4 The aircore platform 200 may interface with other wireless systems. To set up 

5 a call, trunks are established between the two systems. Figures 35-40 are flow charts 

6 that show the message traffic used to establish and reset the trunks. Figure 35 shows 

7 the message flows when a far end system sends a blocking request to the aircore 

8 platform 200. A blocking 700 is received from the BSC 105 and transferred to the 

9 REC 402. The REC 402 returns a REC.AMH.BLOCKING.ACK 703 to the BSC 105. 

10 The state of the trunk circuit established could move to blocked or to blocked pending 

1 1 depending on whether a call is currently on the channel. The REC 402 assures the 

12 appropriate state changes occur. 

13 Figure 36 shows the message flows for resetting a trunk circuit when no call is 

14 in progress. The BSC 105 sends a RESETCIRCUTT 710 which is received at the 

15 REC 402. The REC 402 returns a REC_AMH.RESET.CIRCUIT.ACK 714 to the 

16 BSC 105 and the circuit is reset. 

17 If a call existed on the trunk circuit, the message flows vary from that shown in 

18 Figure 36. Figure 37 shows the message flows in this situation. In Figure 37, the 

19 BSC 105 sends a RESETCIRCUIT 720, which is transferred to the REC 402. The 

20 REC 402 sends a REC_CPM_CLEAR_CALL 723 to the CPM 414. The CPM 414 

21 sends a CLEAR.CALL 724 to the AMH 43 1 . The AMH 43 1 then clears the call. In 

22 parallel, the REC 402 sends a REC_AMH_RESET.CIRCUrr.ACK 725, which is 

23 transferred (726, 727) to the BSC 105. 

24 The trunk circuit may also be reset by action taken by the aircore platform 200. 

25 Figure 38 shows the message flows in this situation. The REC 402 initiates a 

26 REC.AMH.RESET.CIRCUTT 730, which is transferred (736, 738) to the BSC 105. 

27 The AMH 43 1 sets the T12 timer 734 using an AMH.TMR.SET.TIMER (RESET. 

28 CIRCUIT) 733. The BSC 105 returns a reset circuit acknowledgment using 

29 RESET.dRCUIT.ACK 735, which is transferred (736, 738) to the REC 402. 
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1 Because the REC 402 received the reset circuit acknowledgment before expiration of 

2 the T12 timer 734, the AMH 43 1 sends (737) a timer release message to the TMR 437 

3 releasing the T12 timer 734. 

4 In some cases, the BSC 105 will not return a reset circuit acknowledgment 

5 message before expiration of the T12 timer 734. Message flows in this situation are 

6 shown in Figure 39. When the T12 timer 734 times out, AMH 431 (747) sends a time 

7 out message to the REC 402. The REC 402 then repeats the reset circuit procedure n 

8 number of times, where n is a setable parameter. When the nth attempt to reset the 

9 trunk circuit fails, an alarm is raised at the Operations and Maintenance system. The 

10 far end state of the circuit remains in an unknown state. 

1 1 Figure 40 shows the message flows associated with opening a trunk circuit. 

12 The message flows are similar to those in Figure 35. 

1 3 The aircore platform 200 maintains the current location of mobile customers 

14 using the VLR 422 and HLR 424. When a mobile customer enters the region serviced 

15 by the aircore platform 200, the mobile customer's mobile unit 1 12 will register with 

1 6 the aircore platform 200. Figures 41 through 47 show the message flows associated 

17 with this registration process. 

18 Figure 41 shows the message flows associated with the successful updating by 

19 location of a mobile unit 112. The flow assumes the mobile unit's profile has been 

20 previously retrieved and is stored in the VLR 422, and therefore no interaction is 

21 shown with the HLR 424. The BSC 105 sends (760) a location update request to the 

22 aircore platform 200. The request is received at the DH-7 510, which transfers (761) 

23 the update request. 

24 At me 434, the update request triggers authentication processing if the 

25 mobile unit 1 12 operates according to IS-41 protocols. The update request is then 

26 passed (763, 764) to the VLR 422. The VLR 422 updates the active file for the 

27 mobile unit 1 12 and returns a VLR registration notification response to the BSC 105. 

28 When the VLR registration notification response reaches the ARS 434, GSM 

29 authentication and ciphering are completed, if the mobile unit 1 12 operates according 
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1 to GSM protocols. The BSC 105 receives a LOCATION_UPDATING_ ACCEPT 769 

2 message from the DH-7 5 10. The DH-7 510 also provides a CLEAR_COMMAND 

3 771 to the BSC 105. At this time, GSM TMSI reallocation occurs. The BSC 105 

4 sends a CLEAR_COMPLETE 772 to the DH-7 510, which in turn sends a DH-7_ 

5 AMH_TRANSFER 773 to the AMH 43 1 . 

6 Figure 42 shows the message flows associated with location updating in the 

7 event the registration notification request is rejected. Figure 43 shows the message 

8 flows if the mobile unit 1 12 powers down while operating in the vicinity of the aircore 

9 platform 200. 

10 Figure 44 shows the message flows associated with a periodic update in which 

1 1 the mobile unit 1 12 is already registered in the local VLR with the subscriber profile 

12 already having been retrieved from the HLR. The BSC 105 sends a LOCATION. 

13 UPDATE. REQUEST 1400, which is transferred ( 1401) to the AMH 43 1 . The AMH 

14 43 1 sends an AMH_ARS_LOCATION_UPDATING_REQUEST 1402 to the ARS 

15 434. At this point, authentication may be performed (1404) for IS-41 protocol 

16 equipment. The ARS 1406 then sends an ARSJMH_AUTHENTICATION_ 

17 REQUEST 1406 to the IMH 432. The IMH 432 then sends an IMH_VLR_ 

18 REGNOTJREQUEST 1408 to the VLR 422. 

19 The mobile unit 1 12 was previously registered in the VLR 422. Therefore, the 

20 mobile unit's location is simply updated, and a VLR_IMH_REGNOT_RESPONSE 

21 1410 is returned to the IMH 432. The IMH 432 sends an IMH_ARS_ 

22 AUTHENTICATION_RESPONSE 1412 to the ARS 434, which in turn sends (1414) 

23 and authentication result to the AMH 43 1. The AMH 43 1 then sends (1416) a 

24 LOCATION_UPDATING_ACCEPT 1418 to the BSC 105. The aircore platform 200 

25 may also perform GSM authentication and ciphering (1413) and TMSI reallocation 

26 (1419). 

27 The AMH 43 1 sends (1421) a CLEAR_COMMAND 1420 to the BSC 105. 

28 The BSC 105 returns a CLEAR_COMPLETE 1422 to the DH-7 510, which sends a 

29 DH7_AMH TRANSFER 1423 to the AMH 43 1. 
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1 Figure 45 shows the message flows associated with location updating in which 

2 the mobile unit is not currently listed in the local VLR, but is listed in the local HLR. 

3 The initial message flows 1430 - 1438 are the same as shown in Figure 44 (1400 - 

4 1408), including authentication (1434) for IS-43 protocol systems. However, the 

5 mobile unit 1 12 is not listed in the VLR 422. The VLR 422 returns a VLR_IMH_ 

6 REGNOT. RESPONSE 1440 that indicates the mobile unit 1 12 is not registered in 

7 the VLR 422. In response, the IMH 432 sends an IMH_HLR_REGNOT_REQUEST 

8 1442 to the HLR 424. The mobile unit 1 12 is registered in the HLR 424, and the HLR 

9 424 returns an HLR_IMH_REGNOT_ RESPONSE 1444 to the IMH 432. The IMH 

10 432 then sends an IMH_VLR_ REGNOT_RESPONSE 1446 to the VLR 422 to 

1 1 register the mobile unit 1 12 in the VLR 422. In response, the VLR 422 returns a 

12 VLR_IMH_REGNOT_ RESPONSE 1448 to the IMH 432 to indicate that the mobile 

13 unit 1 12 is registered in the VLR 422. The remaining message flows (1450 - 1464) 

14 are similar to those (1412 - 1422) shown in Figure 44. 

15 Figure 46 shows the message flows when the IMH 432 determines that the 

16 mobile unit 1 12 is homed to an external HLR. The IMH 432 makes this 

17 determination based on an identification of the mobile unit 1 12 that is provided with 

18 the initial location update request messages. In Figure 46, the initial message flows 

19 ( 1480 - 1488) are similar to those shown in Figure 44. The VLR 422 notifies the IMH 

20 432 that the mobile unit 1 12 is not registered in the VLR 422. Based on the 

21 identification of the mobile unit 1 12, the IMH 432 then determines that the mobile 

22 unit 1 12 is registered in an external HLR. The identification is used to locate the 

23 external HLR. The IMH 432 sends a MAP_UPDATE_LOCATION_INVOKE 

24 (GSM) or a REGISTRATION. NOTIFICATION_INVOKE (IS-41) 1492, 1493 to the 

25 external HLR. The IMH 432 also sets a REGNOT timer 1496. The external HLR 

26 returns (1494) a MAP_UPDATE_LOCATION_RESULT (GSM) or a 

27 REGISTRATION_NOTIFICATION_RETURN .RESULTS (IS-41) 1495 to the MSC 

28 210. The IMH 432 releases the REGNOT timer 1496 and sends an IMH_VLR_ 

29 REGNOT.RESPONSE 1498 to the VLR 422, causing the mobile unit 1 12 to be 
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1 registered in the VLR 422. The VLR 422 then returns a VLR_IMH_REGNOT_ 

2 RESPONSE 1499 to the IMH 432. The remaining message flows (1500 - 1509) are 

3 similar to those shown in Figure 44. 

4 Figure 47 shows the message flows when the IMH 432 determines that the 

5 mobile unit 1 12 is homed to an external HLR, but the REGNOT timer 1496 times out 

6 before the external HLR returns a response. The IMH 432 makes this determination 

7 based on an identification of the mobile unit 112 that is provided with the initial 

8 location update request messages. In Figure 47, the initial message flows (1510 - 

9 1524) are similar to those shown in Figure 46. When the REGNOT timer 1496 times 

10 out, the TMR 437 sends a TMR_IMH_TIMER(REGNOT) 1525 to the IMH 432. The 

1 1 channel is cleared (1526 - 1535) in a manner similar to that in Figure 47. 

12 Figures 48-71 show the message flows associated with call processing. Figure 

13 48 is a flow chart for a mobile originated call. The mobile originated call begins when 

14 the BSC 105 receives an indication from the mobile unit 1 12 that the mobile unit 1 12 

15 will originate a call. The BSC 105 may receive the number of the called party that 

16 was dialed at the mobile unit 112. 

17 The BSC 105 transmits a CM_SERVICE_REQUEST 800 to the aircore 

18 platform 200 where the message is received and processed by the DH-7 510. The 

19 DH-7 510 establishes the SS-7 link and ensures proper message routing for the 

20 inbound message. The DH-7 510 sends a DH-7.AMH.TRANSFER 801 to the 

21 appropriate AMH 43 1 (either the GSM or the IS 634 thread). The AMH 43 1 sends an 

22 AMH_ARS.CM.SERVICE_REQUEST 802 to the ARS 434. 

23 The ARS 434 provides the appropriate calculations and processing to 

24 authenticate the given base station interface. The ARS 434 then sends an 

25 ARS_DVffl>UTHENTICATION.REQUEST 803 to the appropriate IMH 432. The 

26 IMH 432 sends an IMH.VLR.REGNOT_REQUEST 804 to the VLR 422 to notify the 

27 VLR 422 of the incoming call. The VLR 422 registers the mobile unit 1 12 as an 

28 active unit and then sends a \HUR_IMH_REGNOTJRESPONSE 805 to the appropriate 

29 IMH 432. The IMH 432 sends an IMH_ARS_AUTHENTICATION^RESPONSE 806 
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1 to the ARS 434. If the mobile unit 1 12 uses a GSM protocol, GSM authentication and 

2 ciphering are completed at this point. 

3 The ARS 434 sends an ARS.AMH_AUTHENTICATION_RESULT 807 to the 

4 AMH 43 1 and the appropriate AMH 43 1 sends an AMH.DH-7.TRANSFER 808 to 

5 the DH-7 5 10. The DH-7 5 10 sends a CM_SERVICE_ACCEPT 809 to the BSC 105 

6 indicating to the BSC 105 that the mobile unit 1 12 is allowed to proceed with the call 

7 processing using the aircore platform 200. 

8 During the above-described processing for a GSM protocol mobile unit, the 

9 ARS assigns the call a temporary mobile subscriber identity (TMSI). The TMSI is 

10 calculated based on an index in the VLR 422, the time of day, and the identity (IMSI) 

11 of the mobile unit 112. The TMSI provides additional security so that if the mobile 

12 call is tapped, the identity of the calling mobile party cannot be determined. 

13 In Figure 48, the mobile call process then proceeds to the call setup stage and 

14 the BSC 105 transmits a SETUP 8 10 to the DH-7 5 10. The SETUP 8 10 includes the 

15 call number and an identity of the mobile customer. The DH-7 510 transfers the 

1 6 information to the appropriate AMH 43 1 by sending a DH-7.AMH.TRANSFER 8 1 L 

17 The AMH 43 1 then notifies the CPM 414 that a mobile originated call has been 

18 received by sending a CAIi RECEIVED 812. When the CPM 414 is notified that the 

19 mobile call has been received, the CPM 414 allocates a voice channel for a mobile 

20 call to carry the voice between the aircore platform 200 and the BSC 105. The mobile 

21 call is assigned a session number and each party of the mobile call is assigned an 

22 object of the mobile call. 

23 The AMH 43 1 , the DH-7 5 10 and the BSC 105 communicate through a series 

24 of messages 813-821 that the call assignment request has been made and completed. 

25 During this processing, a T10 timer 818 is used to time out the call in the event a 

26 voice channel cannot be readily assigned. Once the channel assignment is complete 

27 and the radio and voice channels are assigned, the AMH 431 sends a ROUTE.CALL 

28 822 to the CPM 414, informing the CPM 414 to proceed with the call because all of 

29 the incoming wireless communication requirements have been established. The CPM 
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1 414 determines, based on the number that is to be dialed out, what facility the call 

2 should go to and in what format. The CPM 414 sends a MAKECALL 823 to the 

3 appropriate device handler (DHD 501, DHI 503 or DH-7 510) for a land-based or 

4 wired call. If the number to be dialed is for a mobile unit, the CPM 414 sends a 

5 location request (not shown) through the IMH 432 to the HLR 424 to find out where 

6 the called mobile customer is. 

7 As shown in Figure 48, the device handler returns a CALL^ALERTING 824 to 

8 the CPM 414 indicating an attempt to connect to the called party. The alerting 

9 message is then passed to the BSC 105 using an ALERT.CALL 825, AMHJDH- 

10 7 TRANSFER 826 and an ALERTING 827. 

1 1 After the MAKE_CALL 823 is transmitted, the called party should return a 

12 signal to the appropriate device handler, which then sends a CALL.CONNECTED 

13 828 to the CPM 414. The CPM 414 sends a CONNECT.CALL 829 to the AMH 431, 

14 which propagates as a CONNECT 83 1 to the BSC 105. At the same time, the AMH 

15 431 sets a T313 timer 833 using a AMH_TMR_SET_TIMER (CONNECT) 832 to the 

16 TMR 437. The TMR 437 then waits for a connection acknowledgment that indicates 

17 the called party and the calling party are connected. In particular, the BSC 105 sends 

18 a CONNECTACK 834 to the DH-7 510, and the connect acknowledgment is 

19 propagated (835) to the AMH 431. The AMH 431 then releases the T313 timer 833 

20 by sending an AMH.TMR.RECS.TIMER (CONNECT) 836 to the TMR 437. At this 

21 point, the mobile originated call is connected. 

22 Figure 49 shows call processing for normal mobile termination. The aircore 

23 platform 200 receives a call at a device handler 501 or 503. The device handler sends 

24 a CALL RECEIVED 840 to the CPM 414. The CPM 414 forwards a CPMJMH 

25 LOCATE.SUBSCRIBER 841 to the IMH 432 initiating a subscriber location action 

26 (not shown) in which the HLR 424 (not shown) is queried to determine the location of 

27 the called mobile unit 1 12. The IMH 432 returns an IMNCPM_SUBSCRIBER_ 

28 LOCATION 842 to the CPM 414 indicating the location of the mobile 1 12 unit within 

29 the wireless area served by the aircore platform 200. The CPM 414 then initiates a 
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1 CPM.PAG PAGE MOBILE 843 to the PAG 435 to page the called mobile unit 1 12. 

2 The called mobile unit 1 12 is then paged (845, 846) and returns a response (850-852). 
At the same time, the AMH 431 initiates a timer 855 that will timeout the page 
request if a page response from the mobile unit 1 12 is not received within a set time 

5 period. 

6 As shown in Figure 49, once the page response is received, the ARS 434 

7 initiates an ARS.IMH. AUTHENTICATION REQUEST 853 to the IMH 432. The 

8 IMH 432 sends an IMH VLR.REGNOT. REQUEST 854 to the VLR 422 to retrieve 

9 the profile information from the VLR 422 for the mobile unit 1 12. The VLR 422 

10 returns a VLR.IMH REGNOT RESPONSE 857 containing the requested data for the 

1 1 mobile unit 1 12 in the VLR 422. 
During the time period that the mobile unit 1 12 is being paged and the 

authentication and registration notification messages are being passed, authentication 

14 and ciphering, may occur. In particular, for IS-41 protocol systems, authentication 

15 may occur at block 848. For GSM protocol systems, GSM authentication, ciphering 

1 6 and TSMI reallocation may occur at block 859. 

17 As shown m Fig 11 ^ 4 9, when the AMH 43 1 receives the authentication result, 

18 the AMH 431 initiates an AMH PAG PAGE.RESPONSE 861 which is passed (862) 

19 totheCPM414. The CPM 414 then initiates a MAKE CALL 863. Theaircore 

20 platform 200 then proceeds to call setup, channel assignment, alerting, call connection 

2 1 and call connection acknowledgment (864-889). 

22 Fig 1116 50 shows a mobile terminated call in which no response is received to 

23 the PAGE.MOBILE message, and the page timer times out. In Figure 50, the 

24 messages 900-906 are similar to messages 840-846 of Figure 49. An 
AMH. TMR.SET TIMER (PAGE.RESPONSE) 907 is sent by the AMH 431 to the 
TMR 437. When the AMH 431 fails to receive a response to the page request, the 

27 timer 908 times out in the TMR 437, and the TMR 437 sends a TMR.AMH TIMER 

28 (PAGE.RESPONSE) 910 to the AMH 431. The AMH 431 then initiates a series of 

29 messages 91 1 to 916 to update the VLR 422. The CPM 414 receives a PAGE.CPM 
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1 PAGE_RESPONSE 918 indicating no response to the mobile page, and as a result the 

2 CPM 414 does not issue a MAKE_CALL message. 

3 Figure 5 1 shows the message flows associated with a PSTN initiated 

4 disconnect. The device handler (DHD 501 or DHI 503) receives a disconnect signal 

5 from a telephone or other device connected to the PSTN. The device handler sends a 

6 DIS CONNECT_C ALL 930 to the CPM 414, which returns a CLEAR.CALL 932 to 

7 the device handler and issues the CLEAR_CALL to the AMH 932. As a result, a 

8 DISCONNECT (GSM) or RELEASE (IS-634) 934 is sent to the BSC 105, which 

9 returns a RELEASE (GSM) or RELEASE.COMPLETE (IS-634) 938. A T305 or 

10 T306 (GSM) or T308 (IS-634) timer 936 is also set in the TMR 437, and if the 

1 1 RELEASE or RELEASE_COMPLETE 938 is not received before expiration of the 

12 timer 936, the channel is released. 

13 Once the RELEASE or RELEASE_COMPLETE 938 is received, the AMH 

14 43 1 sends a CALL — CLEARED 944 to the CPM 4 14, and a RELEASE_COMPLETE 

15 943 is sent to the BSC 105. The DH-7 5 10 then sends a CLEAR_COMMAND 946 to 

16 the BSC 105, and an internal timer 948 is set in the TMR 437. The BSC 105 returns a 

17 CLEAR_COMPLETE 949, and the internal timer 948 is released. 

18 Figure 52 shows a mobile originated disconnect. A DISCONNECT (GSM) or 

19 RELEASE (IS-634) 960 is received at the DH-7 510 from the BSC 105. The DH-7 

20 510 transfers the message to the AMH 43 1 , which initiates a DISCONNECTCALL 

21 962 to the CPM 414. The CPM 414 initiates a CLEAR.CALL 964 to the AMH 431 

22 and the device handler 501 or 503. The AMH 431 transfers (965) the CLEAR.CALL 

23 964 command to the DH-7 5 10, which initiates a release (GSM) or RELEASE. 

24 COMPLETE (IS-634) 966. The device handler 501 or 503 sends a CALL.CLEARED 

25 967 to the CPM 414. The AMH 43 1 also initiates a T308 timer 964 (GSM) to clear 

26 the channel in case a RELEASE.COMPLETE message is not received from the 

27 mobile unit 1 12 within the time period set by the T308 timer 964. The BSC 105 

28 returns a RELEASE.COMPLETE (GSM) 970 to indicate that the mobile unit 1 12 has 

29 completed disconnect, and the AMH 43 1 releases the T308 timer 964 and sends a 
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CALL CLEARED 975 to the CPM 414. The AMH 431 sends an AMH.DH- 
7.TRANSFER 967 to the DH-7 510, which initiates a CLEAR.COMMAND 977 to 
the BSC 105. The AMH 43 1 also sets an internal timer 980 to clear the channel in the 
event that a CLEAR.COMPLETE message is not received from the BSC 105. The 
BSC 105 then initiates a CLEAR.COMPLETE 978 and the AMH 431 releases (981) 
the internal timer 980. 

Occasionally, a base station may not return a response to the MSC 210 within 
the timeout specified. The message flows for this situation is shown in Figure 53. 
The message flow begins after the service request message flows shown in Figure 48 
(messages 800 - 809) are completed. A SETUP 960 is sent from the BSC 105 and in 
response, the AMH 431 sends a CALLJRECEIVED 991 to the CPM 414 and sets the 
T10 timer 818. Because the BSC 105 does not return a response to the 
ASSIGNMENT, REQUEST 996, the T10 timer 818 times out and the AMH 431 
sends a DISCONNECT_CALL 1000 to the CPM 414 to initiate a clear call sequence. 
The CPM 414 sends a CLEAR.CALL 1001 to the AMH 431, which is passed (1002) 
to the BSC 105 as a DISCONNECT (GSM) or RELEASE (IS-634) 1003. The AMH 
431 also sets (999) a channel release timer 936 in order to release the channel if the 
BSC 105 does not respond to the DISCONNECT 1003. 

The BSC 105 then sends a RELEASE (GSM) or RELEASE_COMPLETE (IS- 
634) 1004, which is transferred (1005) to the AMH 431. The AMH 431 releases 
(1006) the timer 936, sends a CALL.CLEARED 1007 to the CPM 414, and sends 
(1008) a RELEASE_COMPLETE 1009 (GSM) to the BSC 105. The AMH 431 then 
sends (1010) a CLEAR.COMMAND 101 1 to the BSC 105 and sets (1012) an 
internal timer 1013. The BSC 105 returns a CLEAR.COMPLETE 1014, which is 
transferred (1015) to the AMH 431, which then releases (1016) the internal timer 
1013. 

Figure 54 shows the sequence of a time out of the T10 timer 818 for a mobile 
terminated call. The initial message flows are the same as messages 840 - 860 shown 
in Figure 49 and are not repeated in Figure 54. The AMH 431 sends a 
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1 AMH_PAG_PAGE_ RESPONSE 1020 to the PAG 435, which is passed (1021) to 

2 the CPM 414. The CPM 414 sends a MAKE_CALL 1022, which is passed as a 

3 SETUP 1025 to the BSC 105. The BSC 105 returns a CAIJL_CONFTRMED 1027. 

4 The T303 timer 869 is set (1026) and released (1028, 1029). The BSC 105 receives 

5 an ASSIGNMENT_REQUEST 1031, and the AMH 431 sends an AMH_TMR_SET_ 

6 TIMER (ASSIGNMENT J^QUEST) 1032 to set the T10 timer 818. However, the 

7 BSC 105 does not send a response to the ASSIGNMENTJREQUEST 1031, and the 

8 T10 timer 818 times out. As a result, the AMH 414 sends a DISCONNECT_CALL 

9 1036 to initiate tear down of the channel. The CPM 414 then sends a CLEAR_CALL 

10 1037, and the channel teardown proceeds through several message sequences to 

1 1 release the channel and to report that the call is cleared (1038 - 1054) in the same 

12 manner as shown in Figure 53. Coincident with the CLEAR_CALL 1037, the CPM 

13 414 may send the calling party an announcement to inform the calling party that the 

14 call cannot be completed to the mobile unit 112. 

15 Figure 55 shows the message flows associated with a mobile originated call 

16 when the channel assignment fails. Channel assignment failure can occur for a variety 

17 of reasons including when the BSC 105 and the MSC 210 do not agree on the state of 

18 the channel, for example. The BSC 105 and the MSC 210 will not agree on the state 

19 of the channel if the BSC 105 indicates the channel is blocked and the MSC 210 

20 indicates the channel is unblocked, for example. The BSC 105 also may incur a 

21 failure in the establishment of the radio portion of the connection. 

22 In Figure 55, a service request is initiated using the same message sequence 

23 (800 - 809) as shown in Figure 48. The BSC 105 then sends a SETUP 1060, which is 

24 received at the DH-7 510. The message is transferred (1061) to the AMH 43 1, which 

25 sends a C ALL.RECEIVED 1062 to the CPM 414. The call proceeds through call 

26 setup (1063 - 1065) until an ASSIGNMENT_REQUEST 1066 is sent to the BSC 105. 

27 In this case, however, the BSC 105 returns an ASSIGNMENT_FAILURE 1070. As a 

28 result, the MSC 210 proceeds with call tear down (1071 - 1090) in the same manner 

29 as shown in Figure 53 (1002-1016). 
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1 Figure 56 shows the message flow associated with a mobile terminated call 

2 when the channel assignment fails. In Figure 56, the initial messages (840 - 860) 

3 shown in Figure 49 have already been completed. The AMH 43 1 then sends an 

4 AMH_PAG_PAGE_RESPONSE 1095 to the PAG 435, which passes the message 

5 (1096) to the CPM 414. The call setup phase begins with a MAKE_CALL 1097, a 

6 SETUP 1 101, a CALL_CONFIRMED 1 103 and an AS S IGNMENT_REQUEST 

7 1107. 

8 The BSC 105 returns an ASS IGNMENT_FAILURE 1 109, indicating, for 

9 example, that the BSC 105 and the MSC 2 10 do not agree as to the state of the 

10 channel allocated between the BTS and the MSC 210. The AMH 431 sends a 

1 1 DISCONNECT_CALL 1 1 12 to the CPM 414, which returns a CLEAR_CALL 1 1 15. 

12 Call tear down then proceeds in the same manner as shown in Figure 53. 

13 Figure 57 shows the message flows associated with a call disconnect when the 

14 CLEAR_COMMAND internal timer times out. For the PSTN initiated disconnect 

15 and the mobile originated disconnect, the message flows are the same once the 

16 CALL_CLEARED 1 135 is sent by the AMH 43 1 to the CPM 414. The AMH 431 

17 sends (1 136) a CLEAR_COMMAND 1 139 to the BSC 105 and sets (1 137) a 

1 8 CLEAR_COMMAND internal timer 1 138. The BSC 105 does not respond with a 

19 CLEAR_COMPLETE message, and the internal timer 1 138 times out (1 140) 

20 releasing the channel. 

2 1 Figure 58 shows the message flows when the MSC 210 rejects a CM service 

22 request. The BSC 105 sends a CM_SERVICE_REQUEST 1 145 to the MSC 210. 

23 The DH-7 510 determines the protocol of the sending mobile unit 1 12 and spawns an 

24 appropriate thread and forwards (1 146) the CM_SERVICE_REQUEST 1 145 to the 

25 AMH 43 1 . The AMH 43 1 sends an AMH_ARS_CM_SERVTCE_REQUEST 1 147 to 

26 the ARS 434, which forwards an ARS_IMH_ AUTHENTIC ATIONJREQUES T 1 148 

27 to the IMH 432. The ARS in turn sends a registration notification (IMH_VLR_ 

28 REGNOT_REQUEST 1 149) to the YLR 422. The VLR 422 returns a response 

29 (1150) that rejects the service request. This response is passed (1 151) to the ARS 
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1 434, which sends a CM_SERVTCE_REQUEST 1 152 to the AMH 43 1 . The AMH 

2 431 transfers (1153) the rejection to the BSC 105 as a CM_SERVICEJFtEJECT 1154. 

3 Figure 59 shows the message flows associated with a mobile terminated call in 

4 which the CPM 414 times out waiting for an alerting message from the AMH 43 L 

5 The initial message flows are the same as shown in Figure 49 (i.e., 840 - 860). The 

6 AMH 43 1 sends (1 155) a page response to the PAG 435, which forwards (1 156) the 

7 page response to the CPM 414. The CPM 414 sends a MAKE.CALL 1 157 to the 

8 AMH 43 1, which transfers (1 158) the message as a SETUP 1 159 to the BSC 105. 

9 The CPM 414 also sets the T310 timer 876, waiting on receipt of an alerting message. 

10 The BSC 105 returns a CALL_CONFIRMED 1 165, which is passed (1 166) to the 

1 1 AMH 431. A channel assignment is then completed (1 168 - 1 172). However, the 

12 BSC 105 does not send an alerting message to the MSC 210, and the T3 10 timer 876 

13 times out in the CPM 414. As a result, the CPM 414 sends a CLEAR_CALL 1 173 to 

14 the AMH 43 1, which is passed (1 174) to the BSC 105 as a DISCONNECT (GSM) or 

15 a RELEASE (IS-634) 1 175. The call tear down then proceeds (1210-1226) in the 

16 same manner as shown in Figure 53 (1002 - 1016). 

17 Figure 60 shows the message flows associated with a mobile terminated call in 

18 which the call confirmed timer times out in the TMR 437. The initial message flows 

19 are the same as those shown in Figure 49 (840 - 860). The AMH 43 1 sends an 

20 AMHJPAG_PAGEJRESPONSE 1200 to the PAG 435, which forwards (1201) it to 

21 the CPM 414. The CPM 414 sends a MAKE_CALL 1203 to the AMH 431 and sets 

22 the T3 10 timer 876. The AMH 43 1 transfers (1204) the MAKE_CALL 1203 to the 

23 BSC 105 as a SETUP 1205 and sets (1206) the T303 call confirmed timer 869 in the 

24 TMR 437. However, the BSC 105 does not return a call confirmed message to the 

25 MSC 210, and the T303 timer 869 times out ( 1207). The AMH 43 1 sends a 

26 DIS CONNECT_C ALL 1208 to the CPM 414 and the CPM 414 responds with a 

27 CLEAR_CALL 1209. The call tear down then proceeds (1210-1226) in the same 

28 manner as shown in Figure 53 (1002 - 1016). 
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1 Figure 61 shows the message flows associated with a mobile terminated call in 

2 which the call connect timer times in the CPM 414. The initial message flows are the 

3 same as those shown in Figure 49 (840 - 860). The AMH 43 1 sends an 

4 AMH_PAG_PAGE_RESPONSE 1230 to the PAG 435 and call set up proceeds 

5 through make call, call confirmed and channel assignment (1231 - 1245). The BSC 

6 105 then sends an ALERTING 1246, which is transferred (1247) to the AMH 43 1. 

7 The AMH 43 1 sets ( 1248) a T301 call connected timer 883 in the CPM 414. 

8 However, the BSC 105 does not return a connect message, and the T301 timer 883 

9 times out. The CPM 414 sends a CLEAR_CALL 1250 to the AMH 431, and call tear 

10 down proceeds in the same manner as shown in Figure 53 (1002 - 1016). 

1 1 Figure 62 shows the message flows associated with a mobile originated call in 

12 which the BSC 105 does not send a connect acknowledge message to the MSC 210 

13 and the T313 connect acknowledge timer 833 times out. The initial message flows are 

14 the same as shown in Figure 48 (800 - 809). The call proceeds through setup, channel 

15 assignment, alerting and call connection (1270 - 1294). The AMH 431 sets (1293) the 

16 T3 13 connect acknowledge timer 833. However, the BSC 105 does not return a 

17 connect acknowledgment, and the T313 timer 833 times out (1297). The MSC 210 

1 8 then proceeds through call tear down. 

19 Figure 63 applies to GSM and IS-634. Figure 63 shows the message flows 

20 associated with a call disconnect (mobile or PSTN originated) in which the T308 

21 (GSM) release complete timer 964 times out. Similar message flows would exist for 

22 IS-634 protocol equipment. The initial message flows are the same as shown in 

23 Figure 5 1 or Figure 52. The CPM 414 sends a CLEAR_CALL 1300 to the AMH 43 1, 

24 which is transferred (1301, 1302) to the BSC 105. The AMH 431 also sets (1303) a 

25 T308 release complete timer 964. As shown in Figure 63, the BSC 105 does not 

26 return a release complete message and the T308 timer 964 times out (1304). The 

27 AMH 431 then sends (1305) a second RELEASE 1306 to the BSC 105 and sets 

28 (1307) a second T308 timer 964'. The BSC 105 returns a RELEASE_COMPLETE 

29 1308, and the AMH 431 releases (1310) the T308 timer 964'. If the T308 timer 964' 
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1 were to expire, the AMH 43 1 could release the transaction and send a call cleared 

2 message to the CPM 414. The MSC 210 may then go through a call clear sequence. 

3 Returning to Figure 63, the AMH 431 next sends a CALL_CLEARED 1315 to the 

4 CPM 414, sends (1316) a CLEAR„COMMAND 1317 to the BSC 105, and sets 

5 (1318) a clear command internal timer 1319. The BSC 105 returns a 

6 CLEAR_COMPLETE 1320 to the MSC 210. The AMH 431 then releases the 

7 internal timer 1319. 

8 Figures 64-66 show the message flows associated with processing a dual tone 

9 multiple frequency (DTMF) signal. As shown in Figures 64 - 66, the BSC 105 

10 initiates the processing by sending a START JDTMF (1330 in Figure 64) and the 

1 1 CPM 414 returns a CPM_AMH_START_DTMF_ACK (1333 in Figure 64). 

12 Figures 67-71 are flow charts showing message handling associated with call 

13 processing with an HLR (internal or external). 

14 Figure 67 shows the message flows when an incoming call is received at the 

15 MSC 210, a location request is sent to the HLR 424, and the HLR 424 indicates that 

16 the mobile unit 1 12 is operating locally. The DHI 501 sends a C AT J ^RECEIVED 

17 1536 to the CPM 414. The CPM 414 sends a CPM_IMH_LOCATE_SUBSCRIBER 

18 1537 to the IMH 432. The IMH 432 then sends an IMH_HLRJLOCATION_ 

19 REQUEST 1538 to the HLR 424. The HLR 424 returns a response (1539) indicating 

20 that the mobile unit 1 12 is homed on the local system and is operating locally. The 

21 IMH 432 then provides an IMH_CPM_SUBSCRIBERJLOCATION 1540 to the CPM 

22 414 indicating that the mobile unit 1 12 is operating locally. The remaining message 

23 flows 1541 - 1595 are similar to those shown in Figure 49. 

24 Figure 68 shows the message flows associated with an incoming call to a 

25 mobile unit 112 that is operating locally but is homed on an external HLR. The DHI 

26 503 sends a CALL_RECEIVED 1600 to the CPM 414, which sends a CPMJMH_ 

27 LOCATE. SUBSCRIBER 1602 to the IMH 432. Because the mobile unit 1 12 is not 

28 homed locally, the IMH 432 sends a location request 1600/1608 to the external HLR 

29 and sets (1604) a LOCREQ timer 1605. The IMH 432 then receives a return 
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1 1610/1612 from the external HLR and releases (1614) the LOCREQ timer 1605. 

2 Then the IMH 432 sends an IMH_CPM_SUBSCRffiERJLOCATION 1616 to the 

3 CPM 414 indicating the location of the mobile unit's 1 12 HLR. The remaining 

4 message flows 1 620 - 1699 are similar to those in Figure 49. 

5 Figure 69 shows the message flows associated with call processing for a 

6 mobile termination in which the mobile unit 1 12 is homed on the HLR 424 but is 

7 operating externally to the wireless network controlled by the aircore platform 200. In 

8 this case, the mobile unit 1 12 will be registered on an external VLR. The CPM 414 

9 receives a CALL_RECEIVED 1700 and sends a location request 1702 to the IMH 

10 432. The IMH 432 sends a location request 1704 to the HLR 424. Because the 

1 1 mobile unit 1 12 is registered on another wireless network, the HLR 424 sends a route 

12 request 1706 to the IMH 432, which sends an invoke 1710 to the external VLR and 

13 sets a ROUTEREQ timer 1709. The external VLR returns the results 1712 to the 

14 IMH 432, and the IMH 432 releases the ROUTEREQ timer 1709. The IMH 432 also 

15 sends an lMH_HLR_ROUTE_REQUEST_RESPONSE 1716 to the HLR 424 and the 

16 HLR 424 returns a location response 1718. The IMH 432 then sends (1720) the 

17 location of the mobile unit 1 12 to the CPM 414, which issues a MAKE_CALL 1722 

18 to the roaming number provided by the external wireless network serving the mobile 

19 unit 1 12. The process then proceeds through call alerting and call connection. 

20 Figure 70 shows the message flows for call processing for a mobile terminated 

21 call when the mobile unit 1 12 is homed on an external HLR and is operating 

22 externally to the wireless network controlled by the aircore platform 200. The CPM 

23 414 receives a CALL_REQUESTED 1730 from the DHD 501. The CPM 414 then 

24 sends a CPM_IMH_LOC ATE_SUB S CRTBER 1732 to the IMH 432. The IMH 432 

25 sets a timer 1734 and sends an invoke message 1736 to the DH-7 510. The DH-7 510 

26 sends 1736 the invoke message to the external HLR and receives (1738) a response. 

27 The DH-7 510 then sends a results message 1739 to the IMH 432. The remaining 

28 message flows are similar to those shown in Figure 69. 
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1 Figure 71 shows the message flows associated with call processing for a 

2 mobile unit 112 homed on an external HLR but operating within the wireless network 

3 controlled by the aircore platform 200. In this scenario, the mobile unit 1 12 receives a 

4 call that goes initially to the MSC of the external wireless network. The call is then 

5 routed to the wireless network controlled by the aircore platform 200. The MSC 210 

6 receives an invoke message 175 1 from the external HLR. The 1MH 432 then sends a 

7 route request 1752 to the VLR 422. Because the mobile unit 1 12 is roaming, it will be 

8 registered on the VLR 422. The VLR 422 returns a route request response 1753 to the 

9 IMH 432, which sends a roaming number 1754 to the external HLR indicating the 

10 location of the HLR 424. The remaining message flows are similar to those in Figure 

11 49 with the exception that the IMH 432 does not have to locate the mobile unit. 

12 Figure 72 shows the message flows associated with hand off pre-processing 

13 for an ISDN PRI+ protocol. The BSC 105 sends a HANDOFFJREQUEST 1850 to 

14 the DHI 503, which sends a HANDOFF_REQUEST 1852 to the HOP 416. The HOP 

15 416 returns a MEASUREMENT JREQUEST 1854 to the DHI 503, which sends a 

16 HANDOFF_MEASUREMENT_REQUEST 1856 to the BSC 105. The HOP 416 also 

17 sends measurement requests (1854 , /1856 , ) to all base stations capable of handling the 

18 message traffic from the mobile unit for which the hand off is requested. The BSC 

19 105 returns a HANDOFF_MEASUREMENT_RESPONSE 1858 to the MSC 210, and 

20 a MEASUREMENT_RESPONSE 1860 is sent to the HOP 416. Other base stations 

21 likewise return measurement responses (1858', I860') to the MSC 210. The HOP 416 

22 then proceeds with the handoff process. Figure 72 shows the initial message 

23 responses for the ISDN PRI+ protocol. Other protocols use similar initial 

24 measurement flows to establish a target base station for hand off. 

25 Wireless customers can pay for their services in a variety of ways including an 

26 annual subscription and on a monthly basis, for example. In both these cases, the 

27 customer pays for the call actually made (air time) plus a periodic base fee. 

28 Customers can also pay for wireless services in advance through a prepaid system. 

29 Figure 73 is a logical diagram of an aircore prepaid rating system 2100. The aircore 
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1 prepaid rating system 2100 includes a data management module 2101, a rating 

administration module 2102, a distributor data module 2103, and distributor rate plans 
2110 through 21 19. Thus, a distributor can have up to ten different rate plans. Each 
customer can select one of the ten different rate plans for each distributor in the 

5 aircore prepaid rating system 2100. 

6 The distributor can be viewed much like a class of service is viewed in 
routing. The distributor is a classification of rating service that is assigned to certain 
groups of subscribers in the aircore system. A distributor could be a point of sale, a 
corporate customer, or an operator classification for a group of customers. Within 
each distributor, there can be up to ten different rate plans configured. A rate plan 
establishes the air time rates for the plan. The combination of distributor and rate plan 
provide a comprehensive rating schedule for a variety of combinations within the 

13 system. 

14 Within each customer profile 460 (see Figure 20) in the aircore HLR 424, the 
parameter for prepaid service is configured as prepaid or not. The prepaid 
configuration of the customer is controlled via a prepaid check box and associated 
prepaid window and a graphical user interface (see Figure 89). The window is used to 
define the distributor and rate plan that the customer uses for the prepaid service. 
Also, the credited amount for the account is input with the prepaid data. This field 
tracks the amount of service that a customer is allowed on the system. The amount is 

21 updated in real-time to track the usage of the system by the customer. 

A third part of the prepaid system is bill generation that is integrated as part of 
a call record management subsystem. The set of functions available allows the 
operator the ability to create a range of reports based on operator defined hilling 

25 cycles. 

26 1x1 operation, when a customer who has elected a prepaid plan uses the aircore 
prepaid rating system 2100, the customer profile 460 is pulled from the HLR 424 to 
determine the applicable distributor rate plan. The information from the customer 
profile 460 is passed to the CPM 414. The CPM 414 determines if the customer has 
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1 an account balance sufficient to pay for the call. The CPM 414 also determines the 

2 least cost route for the call, including defining the land charge and the air time charge 

3 associated with the destination and time of day of the call to come up with the per 

4 minute charge. This value is then used to set a timer that will indicate when the 

5 customer's account reaches a balance that corresponds to two minutes left on a call. 

6 Once the prepaid call has begun, the timer begins a time out process and when 

7 the two minute position is reached, a tone warning is provided to the customer 

8 indicating that the customer is running out of money. No further warnings are 

9 provided, and once the next two minutes have expired, the TMR 437 sends a message 

10 to the CPM 414 indicating that the time has expired. The CPM 414 then initiates a 

1 1 call cutoff, terminating the prepaid call. In this way, the customer cannot overrun the 

12 prepaid account balance 

13 At the completion of the call, the billing system 260 calculates how much the 

14 call actually cost for the customer and updates the amount in the HLR 424. A call 

15 detail record (CDR) is prepared that provides the detailed information regarding the 

16 call so that the billing system 260 can determine the remaining account balance. The- 

17 bill generated by the billing system 260 is then used to update the customer profile 

18 460. 

19 In the wireless environment shown in Figure la- Id, there may be a need to 

20 locate customers who place distress, or emergency (911), calls. These 911 calls are 

21 used to gain rapid access to local authorities and emergency service centers, if a 

22 customer places a 91 1 call from a wired device, locating that customer is easy using 

23 call tracing procedures. Customers using wireless devices are more difficult to locate. 

24 The air core platform 200 solves the problem of wireless customer location by 

25 creating an identification number based on the current position of the customer in the 

26 wireless environment. The aircore platform 200 uses the identification number as the 

27 dialed number to route the call to an emergency service center. The identification 

28 number includes the position data available from the BSS where the call origination is 

29 received. The location information received from the BSS is coded in hexadecimal. 
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The aircore platform 200 converts the hexadecimal number to binary coded decimal 
(BCD) and uses this number as an indication of the customer's location. 

Following is an example of the data conversion used by the aircore platform 
200 to convert the location data received from the BSS 1 10 to a dialed number for 
emergency callers. The data received could be as shown in the following table in 
which the BSS 1 10 receives the location of a customer with cell ID granularity. The 
MSC 210 converts the data as shown in the table. 
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FIELD 


RESULTING NUMBER OF DIGITS 


Mobile Country Code 


Up to 3 


Mobile Network Code 


Up to 3 


Location Area ID 


Up to 3 


Cell ID 


Up to 3 



The numbers produced from the conversion yields a unique 12 digit number 
identifying that cell in the system. 

The aircore platform 200 may incorporate the concept of customer groups to 
define the routing translations (classes of service) for the wireless network. A 
customer group is a table of number ranges that is used to determine if a call is 
allowable. The aircore platform 200 searches the list of entries in the table. If a 
match is found, the call is allowed to proceed. If a match is not found, the call is not 
allowed to proceed in the wireless network. 

The aircore platform 200 allows for the definition of up to 256 different 
customer groups. Each customer in the system, and each trunk, is associated with a 
customer group when a customer group is initially configured. The customer group 
that is used for a particular call is determined based on: 1) the customer placing the 
call; and 2) the trunk that received the call. 
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1 For emergency calls, a specific customer group is used to provide the routing 

2 translations. For emergency calling, the aircore platform 200 uses emergency 

3 translations. 

4 Figure 74 is a flow diagram illustrating emergency call processing using the 

5 aircore platform 200. The processing starts as step S 100. In step SI 10, the call is 

6 received at the aircore platform 200. The process then moves to step S 120. In step 

7 S 120, the aircore platform 200 determines if the call is an emergency call. If the call 

8 is not an emergency call, the process proceeds to step SI 30 and the call is handled as a 

9 normal call. In step S 120, if the call is an emergency call, the process moves to step 

10 S 140. In step S 140, the aircore platform 200 converts the location of the mobile unit 

11 to a dial-up number. The process then moves to step S 150. 

12 In step S 150, the aircore platform 200 checks the portion of the customer 

13 group associated with emergency calls. The process then moves to step SI 60. Instep 

14 SI 60, the aircore platform 200 determines if the dial-up number from step S 140 is in 

15 the customer group. If the dial-up number is not in the customer group, the process 

16 proceeds to step S 170, and the call is routed to a default emergency center. If the dial- 

17 up number is the customer group, the process moves to step SI 80. In step S 180, the 

18 aircore platform 200 changes the dial-up number to an emergency center number. The 

19 process then moves to step S 190. In step S 190, the call is routed to the emergency 

20 center. The process then moves to step S200 and ends. 

21 The aircore platform 200 can also support other communication features. For 

22 example, the aircore platform 200 may be used with a long-distance resale system. 

23 The aircore platform 200 can also be used to provide microcellular wireless 

24 networks in combination with land-line local networks or private branch exchanges 

25 (PBX). There are several standards including computer supported 

26 telecommunications applications (CTS A), windows telephony application 

27 programming interface (TAPI), and telephony services application programming 

28 interface (TSAPI), for example, that allow a PBX to incorporate equipment and 

29 features from outside vendors. These protocols also allow for call control and routing 
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1 decisions to be made by a system that is external to the PBX. The external system can 

2 be used to allow for connectivity, feature processing, and seamless number 

3 management that allows customers to use both the PBX infrastructure and a separate 

4 wireless system using one telephone number and one customer feature profile. 

5 The aircore platform 200 provides an external control function to integrate a 

6 wireless system, or microcell, and a PBX using the technique of third party call 

7 control. Figure 75 is a diagram illustrating first party call control. In Figure 75, an 

8 application 2010 controls a call from a PBX 201 1 to a telephone 2014. The control of 

9 the call is related to each of the signals and messages passed between the telephone 

10 2014 and the PBX 201 1 . First party call control is often used as a call control feature 

11 in private branch exchanges. 

12 Figure 76 illustrates third party call control. In Figure 76, a call control 

13 application 2015 provides direct control over termination of a call to the resource such 

14 as the telephone 2014. Calls into a PBX 2016 are routed under the control of the call 

15 control application 2015. The aircore platform 200 can incorporate the concept of 

16 third party call control to add on to the functionality of a PBX. In particular, the 

17 aircore platform 200 may be used with a PBX to add in-building wireless 

18 communication capabilities to an existing wired private branch exchange. 

19 A standard PBX interface control element (SPICE) may be added to the 

20 aircore platform 200 to provide an interface to a PBX. The SPICE includes software 

21 that can operate with the control protocols of different PBXs. The SPICE interfaces 

22 internally with the HLR 424 and the SCR 3 14 (see Figure 10). A system operator may 

23 interface with the SPICE using a graphical user interface (GUT). 

24 The SPICE provides third party call control messaging needed to provide the 

25 notice of an incoming call, decide how to handle the incoming call and send the 

26 appropriate commands to route the incoming call to the correct destination. The 

27 SPICE may be co-located with the HLR 424, and requires the basic retrieval 

28 capabilities of the HLR 424. The customer profile information in the HLR 424 allows 

29 the SPICE to determine how to handle a call. For example, the customer profile may 
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1 indicate the operational modes for the customer's wired and wireless telephone 

2 handsets. 

3 Customers whose PBX incorporates wireless features, including the SPICE, 

4 noted above, may designate one or more operational modes for their telephone 

5 handsets. Customers may elect to have incoming call terminate at their desktop 

6 telephone first. If the desktop telephone is not available, the call may be routed, via a 

7 MSRN, to the customer's mobile unit. Second, the call may be first routed to the 

8 mobile unit. If the mobile unit is not available, the call may be routed to the desktop 

9 telephone. Third, the call may be routed to the customer's mobile unit only. Fourth, 

10 the call may be routed to the customer's desktop telephone only. Fifth, the call may 

11 be routed to the mobile unit only when operating in the mobile unit's 112 home area. 

12 One advantage of this arrangement is that the HLR 424 may house the full 

13 suite of call forwarding features, voice mail and announcements. The customer's 

14 profile determines how the call is handled. 

15 If the customer profile indicates that incoming calls are first routed to a mobile 

16 unit, the HLR 424 will locate the customer in the telecommunications network and 

17 then have an MSRN allocated to deliver the call to the switch where the customer's 

18 mobile unit is residing. 

19 If the customer profile lists the desktop telephone as the first call delivery 

20 option, the SPICE determines that the call should be terminated to the desktop 

21 telephone. If the customer answers the desktop telephone, SPICE's involvement in 

22 the call ends. However, if the customer does not answer at the desktop telephone, 

23 SPICE processing can determine the appropriate handling for the call. The call could 

24 be routed to the mobile unit, voice mail, or an announcement, for example. 

25 Figures 77 - 79 illustrate call routing for various call entry points. In Figure 

26 77, a PBX 2020 receives an incoming call from a PSTN (not shown). The PBX 2020 

27 uses third party call control over a CSTA interface (not shown) to notify (2022) a 

28 HLR 2030 that a customer has received an incoming call 2021. The HLR 2030 

29 determines that the customer is currently roaming on another wireless telephone 

-79- 



BNSOOCID: < WO 0O46938A 1 J A> 



WO (10/46938 PCT/USOO/027!>7 



1 system, and that the call needs to be delivered to the customer. Using standard mobile 

2 application messaging, the appropriate number for the delivery is allocated and sent 

3 (2023) to the PBX 2020. Via the CSTA interface, the PBX 2020 is commanded to 

4 send the call over the PSTN with the delivery number as the destination. The call 

5 arrives at a local MSC 2025 and is delivered (2037, 2038) via a wireless network 2035 

6 to a mobile unit 2036. 

7 Figure 78 shows a scenario for call delivery to the mobile unit 2036 when the 

8 local MSC 2025 is the point of entry for the call from the PSTN (not shown). An 

9 incoming call 2040 is received from the PSTN at the local MSC 2025: The MSC 

10 2025 communicates (2041) with the HLR 2030 for call delivery information. The 

1 1 HLR 2030 determines that the customer is roaming on another wireless network 2035 

12 and that the call should be delivered to the wireless network 2035. The appropriate 

13 number for delivery is allocated and sent (2039) to the MSC 2025. The MSC 2025 

14 then delivers (2042, 2043) the call to the mobile unit 2036. 

15 Figure 79 shows a scenario for call termination to a desktop telephone. In 

16 Figure 79, the local MSC 2025 receives an incoming call 2045 from the PSTN (not 

17 shown). The MSC 2025 communicates with the HLR 2030 for call delivery 

1 8 information. The HLR 2030 determines that the customer is not registered in the 

19 wireless network 2035 and determines that the call should be terminated to the PBX 

20 2020. The HLR 2030 allocates (2047) a delivery number for the PBX 2020. Using 

21 standard procedures, the HLR 2030 sends the delivery number to the MSC 2025. The 

22 MSC 2025 then delivers (2048) the call 2045 to the PBX 2020. Using third party call 

23 control, the HLR 424 associates the call 2045 with a customer and the call 2045 is 

24 terminated to the desktop telephone 20 14. 

25 Figure 80 shows an aircore platform 2200 that is used to provide an in- 

26 building wireless and wired telephone system with third party call control. A building 

27 2210 includes a PBX 221 1. The PBX 221 1 connects to wired telephones 2212. The 

28 building 2210 also includes a microcellular wireless network 2201 serving mobile 

29 units 22 13. The PBX 22 1 1 connects to the aircore platform 2200 via wired a 
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1 connection and a suitable interface such as a RS-232 interface. The aircore platform 

2 2200 includes a base station controller 2206 and a suitable interface to provide 

3 wireless communication to the microcellular network 2201. The BSC 2206 may be 

4 incorporated as a component on a card in the aircore platform 2200. A separate 

5 database 2205, containing information related to customers of the building 2210 may 

6 be provided with the aircore platform 2200. Alternately, the data may be included in a 

7 home location register in the aircore platform 2200. Finally, macro cellular systems, 

8 such as the extended wireless network 2220 with cells 2221 and 2222 may exist 

9 external to the microcell 2201 . 

10 In operation a customer using both a wired telephone 2212 and a mobile unit 

11 2213 may specify, by entry in the database 2205, for example, which of the wired 

12 telephone 221 1 and mobile unit 2213 should receive a call. Thus, when a call comes 

13 in to a particular customer, the aircore platform 2200 will determine which of the 

14 wired telephone 2212 and the mobile unit 2213 to connect to first. The aircore 

15 platform 2200 can be further instructed that when the mobile unit 2213 is active, or in 

16 a power-on state, all calls should first be routed to the mobile unit 2213. If the mobile 

17 unit 2213 does not respond after a certain number of rings, the incoming call can then 

18 be routed to the wired telephone 2212. The microcellular network 2201 may also be 

19 used for visitors to the building 2210. In this case, a visitor having a mobile unit may 

20 have that mobile unit initiate a registration notification when the mobile unit enters 

21 the microcellular network 2201. Then, any incoming calls to the visitor's mobile unit 

22 will be routed through the aircore platform 2200 to the microcellular network 2201 . 

23 When a customer of the building 2210 transits from the microcellular network 

24 2201 to the external wireless network 2220, a location update is performed that 

25 deletes the customer's location in a VLR of the microcellular network 22Q1, and 

26 initiates a registration notification with the mobile switching center of the external 

27 wireless network 2220. In this way, the exact location of the mobile unit 2213 may be 

28 maintained so that calls to a particular customer may be routed in accordance with the 

29 customer's routing plan contained in a VLR/HLR or the database 2205. 
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1 In the arrangement described above, a particular mobile unit 2213 and wired 

2 telephone 2212 may share a common telephone number. In an alternate arrangement, 

3 the wired telephone 2212 and mobile unit 2213 may have different telephone 

4 numbers. 

5 A microcellular network, such as the microcellular network 2201, may also be 

6 adapted for use in large buildings, such as indoor stadiums and convention centers. A 

7 mobile switching center such as the aircore platform 2200 may incorporate multi- 

8 protocol processing and base stations so that visitors to the convention center may use 

9 mobile units inside the convention center regardless of the protocol established for the 

10 mobile unit. The aircore platform 2200 may be configured to charge different rates 

1 1 for different visitors to the convention center. People who work in the convention 

12 center may be charged yet another rate for using mobile units in the convention center. 

13 The aircore platform 200 may incorporate fault resilient features, which may 

14 be particularly desirable for distributed wireless systems. The fault resilient hardware 

15 architecture of the aircore platform 200 may be logically split into three layers as 

16 shown in Figure 8 1 . A hardware architecture 2300 includes a computing element 

17 layer2310. The computing element layer 23 10 includes computing elements 2311 

1 8 and 23 12. The computing elements 23 1 1 and 23 12 are connected by an appropriate 

19 communications medium such as an ethernet 2313. The ethernet 23 13 may have a 

20 capacity of 100 Mb or more, for example. 

21 An input/output (I/O) processor layer 2320 includes I/O processors 2321 and 

22 2322. The I/O processors 2321 and 2322 are connected by an appropriate 

23 communications medium such as a 100 Mb ethernet 2323. The I/O processors 2321 

24 and 2322 are both connected to each of the computing elements 23 1 1 and 2322 by an 

25 appropriate communications medium such as a 40 Mb fiber optic cable 23 14. 

26 A telephony interface processor (TIP) layer 2340 includes a plurality of 

27 telephony interface processors (TIPs) 234^ - 2341 n . The TIPs 2341 j - 2341 n are 

28 connected by a dual rail ethernet 2343. The ethernet 2343 is also used to connect the 

29 TIPs 2341 , - 2341 n with the I/O processors 2321 and 2322. 
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1 The three layers described above comprise the three main processing areas of 

2 the aircore platform 200. Communications between the three layers provides for a 

3 variety of physical layouts and geographical configurations. For example, the fiber 

4 optic connection between the computing element layer 23 10 and the I/O processor 

5 layer 2320 can be geographically separated by 1.5 kilometers or more. The TIPs 

6 2341 ! - 234 l n can be spread geographically and remotely controlled via a centralized 

7 computing element layer and I/O processor layer set. Thus, the aircore platform 

8 architecture 2300 can be adapted to provide a large distributed wireless network with 

9 centralized control or the layers can be co-located. 

10 Figure 82 shows the logical construction of the computing element 231 1 in 

1 1 more detail. The computing element 23 12 is identical to the computing element 23 1 1 

12 and therefore, only the computing element 23 1 1 will be described. The computing 

13 element 23 1 1 includes a central processor 23 15, a memory 23 16 and a PCI-based 

14 connector 23 17 that couples the computing element 23 1 1 to the I/O processors 2321 

15 and 2322. Also shown is a memory 23 18 that stores the software applications that 

16 operate in the computing element 231 1. The software applications are described with 

17 reference to Figure 10. The memory 23 16 may be a random access memory (RAM), 

18 for example. The memory 2318 may be a read only memory (ROM), for example, 

19 Figure 83 shows the logical construction of the I/O processor 2321 in more 

20 detail. The I/O processor 2322 is identical to the I/O processor 2322 and therefore 

21 only the I/O processor 2321 will be described. A PCI interface 2332 connects the I/O 

22 processor 2321 to the ethernet 23 14. A memory module 2326 includes a hard disk 

23 2327, an interface slot 2328 for a CD-ROM, and an interface 2329 for a floppy disk. 

24 A memory 2325 includes the programming to operate the I/O processor 2325. A 

25 central processor 2324 controls operation of the I/O processor 2325. An ethernet 

26 interface 2330 provides connections to the ethernet 2323 and to the dual rail ethernet 

27 2343. A memory 2333 stores application programs executed by the I/O processor 

28 2321. Finally, SS-7 interface modules 2334 and 2335 provide connections to systems 

29 external to the aircore platform 200. 
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1 Figure 84 shows the logical construction of the TIP 2341 The other TIPs are 

2 the same as the TIP 2341 A central processor 2344 controls operation of the TIP 

3 2341 ,. A memory 2345 includes the operating programs for the TIP 2341 ,. A 

4 memory 2348 includes the application programs under control of the TIP 2341 ,. The 

5 application programs are described with reference to Figure 10. An interface 2347 

6 connects the TIP 2341 , to the dual rail ethernet 2343. A memory module 2346 

7 includes a hard drive 2349 and a floppy disk interface 2350. An external interface 

8 module 2349 connects the TIP 2341 x to systems external to the aircore platform 200. 

9 Figure 85 shows another hardware embodiment of the aircore platform 2400. 

10 In this embodiment, the aircore platform 2400 includes a 19-inch rack-mountable 

1 1 chassis 2410. The aircore platform 2400 includes dual loadsharing power supplies 

12 2420 and optional power supplies 2422. The chassis also includes dual mirrored SCSI 

13 disk drives 2430 and optional drive bays 2432. An I/O processor board 2440 connects 

14 to telephony boards slots 1-14 for telephony boards 2470-2485. Finally, the aircore 

15 platform 2400 includes a removable fan tray 2490. 

16 Figure 86 shows the I/O processor in more detail. The I/O processor board 

17 2440 includes a processor 2441 that provides bus control for the telephony boards 

18 2470-2485. The processor 2441 can be an advanced processor such as an Intel 

19 Pentium™ family processor or other processor. The I/O board 2440 also includes a 

20 scalable random access memory 2442. The I/O processor board 2440 provides on- 

21 board PCI video 2443, IDE 2444 and SCSI drive controllers 2445, and multiple serial 

22 I/O ports 2446. Also included are Ethernet connections 2447, floppy disk drives 

23 2448, and PCMCIA slots 2449. The I/O processor board 2440 provides front and rear 

24 access to the I/O devices. The SCSI drives 2445 may be dual mirrored 1.5 Gb hard 

25 drives. The SCSI drives 2445 may be configured in a RAJDD-1 format. The SCSI 

26 drives 2445 are hot swapable and can be resynchronized in case of failure. 

27 The aircore platform 2400 may provide for local network connectivity and 

28 dial-out access using a standard lObase-T or lOObase-T Ethernet connection for LAN 

29 connecting options and a 56k dial-up modem for remote access dial-in capability. 
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1 Other advanced telecommunications connection devices may also be used with the 

2 aircore platform 2400. Standard telephony boards may be used with the aircore 

3 platform 2400 for T-l/E-1 and ATM communications. For example, the telephony 

4 boards 2470-2485 include TH-B 1240 OCTAL T- 1/E- 1 interface boards for common 

5 channel signaling based T-ls. TH-BD96 quad T-l interfaces are provided for channel 

6 associated signaling using T-ls. TH-BD120 quad E-l interface devises are used for 

7 channel associated signaling using E-ls. TH-BV30 voice I/O provides 30 ports of I/O 

8 and signal processing. TH-BC64 provides conferencing capabilities. A TH-BSS7 

9 board provides both DS0 and V.35 connections. Each of the telephony boards 2470- 

10 2485 provides 4-6 trunk links. Also connected to the aircore platform 2400 are 

1 1 operator interface devices including a monitor 2491, a keyboard 2492, and a mouse 

12 2493. 

13 The switching architecture of the aircore platform 2300 or 2400 may be the 

14 H.1 10/H.100 based standard, for example. The H.1 10 and the H.100 switching matrix 

15 is a standard Application Specific Integrated Circuit (ASIC) that resides on each board 

16 in the system. This means that rather than shipping all interface channels to a single 

17 point in the system to make and break the connections for switching, each board 

18 controls its own switching. The H.1 10 switching matrix uses a J4 connector or 

19 connects to the other components of the aircore platform 2400 using a J4 connector on 

20 a back plane of the chassis 2410. There may be a total of 32 streams running at 

21 speeds of 8MH^ Each stream provides 128 channels of 64 kbps. Total bus capacity 

22 ranges from 5 12 to 4096 channels. 

23 The H. 100 switching matrix uses a ribbon cable to connect to boards together 

24 to provide the actual streams of digitized channels. There are a total of 32 streams 

25 running at speeds of IMH^. to SMH^. Each stream provides from 32 to 129 channels 

26 of 64 kbps. The total bus capacity ranges from 5 12 to 4096 channels. 

27 Other switching matrices may also be used with the aircore platform 2400. 

28 The capacity of the aircore platform 2400 may be extended. Multi-chassis 

29 configurations can be provided to claim the switch matrices together. This may be 
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1 accomplished using several standard multi-chassis interconnection interfaces or by 

2 connecting the chassis via E-l or T-l connections. The addition of ATM allows for a 

3 standard extension mechanism to the switch matrix between chassis. 

4 Other hardware configurations besides the two embodiments described above 

5 are available with the aircore platform 200. 

6 The aircore platform 200 incorporates graphical user interfaces (GUIs) to aid 

7 operator manipulation of system data. Figures 87-1 19 show the hierarchy of windows 

8 used with the GUIs and also show examples of GUI screens used with the aircore 

9 platform 200. 

10 Figure 87 shows the hierarchy of windows used with the aircore HLR 424. A 

1 1 hierarchy 3000 includes a home location register icon screen 3001 which is initially 

12 displayed. Upon entry of a password in a password screen 3002, a home location 

13 register access screen 3003 is displayed. Using the home location register access 

14 screen 3003, an operator can choose one of the screens 3004-3009 for GSM, CDMA, 

15 TDMA, AMPS, multi-mode protocols, or for prepaid services. Finally, corresponding 

16 to each of the wireless protocols is a separate prepaid screen 3010-3014. 

17 GSM subscriber profiles are configured as per the GSM feature set. CDMA 

18 subscriber profiles are configured as per the CDMA (IS-664) feature set. Multi-mode 

19 subscriber profiles may be configured for multiple air interfaces. Multi-mode 

20 subscribers use the common feature set between the GSM, CDMA, TDMA and 

21 AMPS protocols. All of the above subscriber profiles can incorporate prepaid feature 

22 functionality. 

23 . Prepaid subscriber profiles are configured as strictly prepaid in the aircore 

24 system. Prepaid subscribers may use wireless or wireless prepaid features. 

25 Figure 88 shows the GSM subscriber window 3004 in more detail. A number 

26 of subscribers block 3021 lists the current number of subscribers in the HLR 424 as 

27 well as the capacity of the HLR 424. The subscriber list 3022 individually lists the 

28 subscribers to the aircore systems. A previous button 3025 and a next button 3026 

29 loads the previous or next group of subscribers into the subscriber list scroll box 3022. 
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1 A properties button 3023 allows modification of data for the selected subscriber. A 

2 search button 3024 allows for search of the HLR 424 when a subscriber MSISDN 

3 number is input at the search line. An add button 3027 and a delete button 3028 allow 

4 the addition or deletion of a subscriber profiled in the HLR 424. A report button 3029 

5 allows an operator to view a change report file created for HLR 424 modifications. 

6 Figure 89 is an example of an individual subscriber profile for a GSM 

7 subscriber. The subscriber profile 3030 includes a customer and mobile unit 

8 identification block 3031, call offering block 3032, call restriction block 3033, and 

9 call restrictions block 3034. Also included is a call features block 3035, and line 

10 identification block 3036. 

1 1 Subscriber profiles for other wireless protocols are similar to that described 

12 above for a GSM subscriber. 

13 Figure 90 shows a routing administration windows hierarchy 31 10 associated 

14 with establishing routing translations in the aircore systems. The initial screen is a 

15 database management icon screen 3101. Next, a routing administration tab 3102 is 

16 display. Linked to the routing administration tab 3 102 is a customer group properties 

17 screen 3 103. Also linked to the routing administration tab 3 102 is a standard routing 

18 screen 3104, a feature codes screen 3105, an emergency call routing screens 3106 and 

19 a tones and announcement screen 3 107. The data displayed in the screens 3 104-3 107 

20 may be modified by displaying an add/modified/delete screen 3 108, 

21 Figure 91 shows the routing administration tab 3102. A customer group scroll 

22 box 3111 shows the customer groups that are currently active in the aircore system. 

23 The customer group is a required piece of data that is assigned to both customers and 

24 trunk groups. The number assigned is used as an index into the appropriate routing 

25 table for processing an incoming call. The routing translations determine the 

26 allowable calls, the type of call, and the appropriate system routing for the call. Each 

27 customer group can accommodate hundreds of individual from-to routing translation 

28 entries. The translations can provide support for any dialing plan between 1 and 32 

29 digits. Dialing plans of varying lengths maybe configured within the same customer 
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1 group. Each line of translations within each customer group provides a primary and 

2 alternate route based on the trunk group. In addition, each route is provided its own 

3 digit manipulation parameters (strip and prefix digits). The aircore system can 

4 accommodate up to 100 customer groups. 

5 Figure 92 shows a customer group modification window 3 120. The customer 

6 group modification window 3120 defines the overall properties associated with a 

7 particular customer group. Check boxes 3121 allow for the configuration of three 

8 alternate types of translations. 

9 Figure 93 shows the standard routing translation window 3104. A scroll box 

10 3131 is used to display portions of the information. The information displayed in the 

1 1 scroll box 3131 includes "from" data, which is the number the range starts from; "to" 

12 data, which is the number the range ends at; min, which is the minimum length of the 

13 digit string; max, which is the maximum length of the digit string; and type, which is 

14 the type of call the number range indicates. Also shown is the route number of the 

15 trunk and the numeric trunk group number. 

16 Figure 94 shows the standard routing translations modifications window 3108. 

17 The standard routing translations modifications window 3 108 provides the operator 

18 access to modify the selected number range. The window is used for adding or 

19 modifying ranges in the standard routing translations window 3 104. 

20 Figure 95 shows the feature code routing translation window 3105. The 

21 feature code routing translation window 3105 includes a scroll box 3151 that displays 

22 a portion of the information selected by the operator. The feature code routing 

23 translation window 3 105 contains the information related to routing feature 

24 manipulation calls for the aircore system. The parameters supplied in the feature code 

25 routing translation window 3 105 are used to determined the type of feature 

26 manipulation and the appropriate system action. 

2 ? Figure 96 shows the emergency call routing translations window 3106. A 

28 scroll box 3161 displays currently selected information. The information includes 

29 "from" data which is the number the digit range starts from. The "from" data can be 
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1 indicated by a code such as 91 1 or can be represented as a cell site. The aircore 

2 system operator can use the emergency call routing translations window 3 106 to route 

3 all emergency calls to a specific number or to establish a trunk group used exclusively 

4 for emergency call routing. 

5 Figure 97 shows the treatment routing translations window 3 107. The 

6 treatment routing translation window 3 107 contains information relate to routed calls, 

7 which are to be treated to an appropriate treatment option, which may be a tone or 

8 announcement. In Figure 97, a scroll box 3171 includes an ID, which is the number 

9 of the treatment in the aircore system, a description 3 172, which is the alpha-numeric 

10 description of the treatment, a first option (1 st Route) 3173, which is the first option 

1 1 for treating the call (typically configured to an announcement or tone) and a second 

12 option 3 174, which is the second option to use if the first option 3173 is not available 

13 (typically set to a standard tone). Failure to use the first option 3173 indicates that all 

14 of the announcement resources are currently in use. 

15 The aircore system includes graphical user interfaces that allow the operator to 

16 perform maintenance actions on individual trunks in the system. When this option is. 

17 chosen in an administration pull down menu (not shown), the operator first selects the 

18 appropriate span and channels, then executes maintenance commands as required. 

19 Figure 98 shows the hierarchy of windows used for trunk maintenance. In Figure 98, 

20 the hierarchy 3200 includes a control panel window 3201, an administration window 

21 3202, a facilities selection window 3203, and a digital trunk maintenance window 

22 3204. 

23 Figure 99 shows the facilities selection window 3203. The window 3202 

24 allows an operator to select the appropriate facilities in the aircore system to be 

25 viewed for maintenance actions. 

26 Figure 100 shows the digital trunk maintenance window 3204. The digital 

27 trunk maintenance window 3204 allows the operator to view the trunk configuration 

28 of a particular span and to change the state of the channels on that span. In the 

29 window 3204, data that is grayed out represents non-configured channels. Channels 
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1 can be configured via a system configuration option on the administration pull-down 

2 menu. Figure 100 shows the digital trunk maintenance window for T-l trunk 

3 maintenance. A similar window is available for E-l trunk maintenance. 

4 Figure 101 shows the aircore configuration windows hierarchy 3300. The 

5 system configuration 3301 is accessed from a control panel graphical user interface 

6 (not shown). This allows the operator to access setup and configuration files. The 

7 operator has access to the configuration of both hardware and software parameters 

8 associated with system operation. Subordinate windows in the system configuration 

9 hierarchy 3300 include a trunk group window 3302 and a board configuration window 

10 3303. Associated with the trunk group window 3302 is a trunk group configuration 

1 1 window 3304. Associated with the board configuration window 3303 is a T-l/E-1 

12 board configuration window 3305, a voice I/O window 3306, a conference window 

13 3307, a SS7 window 3308, and an analog window 3309 and span configuration 

14 windows 3310 and 3312. 

15 Trunk group configuration is part of the system configuration of the aircore 

16 GUI. A trunk group is a logical assignment of characteristics to physical resources in 

17 the aircore system. Trunk groups are used to inform both the low level and high level 

18 software in the aircore system of how to process a call. Trunk groups also allow the 

19 operator to partition the system for specialized use by groups or subscribers. Figure 

20 102 shows the trunk group selection window 3302. A properties button 3322 is used 

21 to access the trunk group configuration window 3304. 

22 Figure 103 shows the trunk group configuration window 3304. When a valid 

23 trunk group number is input in the selection window 3302, and the property button 

24 3322 is pushed, the configuration window 3304 appears. The trunk group 

25 configuration window 3304 includes the sequential number assigned to the trunk 

26 group and an alpha-numeric name associated with the trunk group. The name given to 

27 the trunk group is used to identify the individual circuits configured within the trunk 

28 group. 

-90- 

BNSDOCID: <WO 0046938A1_IA> 



WO 00/46938 



PCT/US00/02797 



Figure 104 shows the board configuration window 3303. The aircore board 
level configuration is accomplished via the board configuration window 3303 and 
subordinate windows. The board configuration window lists the possible board slots 
in the hardware component (installed or not) in a particular slot. To access the 
configuration of the particular board, the operator selects a desired board and operates 
the property button 3332. 

Figure 105 shows the T-l/E-1 board configuration window 3305. A span click 
box section 3381 allows an operator to choose which span to configure. The window 
3305 is used for configuration of the T-l and E-l boards in the aircore system. Based 
on the board type selected, the appropriate number of spans and channels are 
accessible to the operator for configuration. The window shown in Figure 105 is used 
for configuration of the 4-span T-l board, for the CPCI and PCI bus types. Similar 
windows are used for other span and channel configurations. 

Figure 106 shows the T-l/E-1 span configuration window 3310. The T-l/E-1 
span configuration window 3310 appears when a span (A-H) is selected from click 
box 3381 in the T-l/E-1 board configuration window 3305 shown in Figure 105. The 
window 3310 contains the data associated with a particular T-l or E-l span on the 
board. Similar windows are available for other span configurations. 

Figures 107-109 show the windows for the voice I/O board configuration, the 
conference board configuration, and the SS-7 board level configuration. These 
windows are similar to that shown in Figure 106. 

The aircore system generates call detail records (CDRs) to track system 
resource usage and call traffic for customers. Each CDR contains information 
pertaining to a particular part of a call. A CDR is a record created whenever there is 
call activity on the aircore system. The CDR manager is a subsystem in the aircore 
system responsible for generating and storing this information. The CDR manager 
provides the operator with a complete set of options for viewing data both real time 
and archive, monitoring traffic on the aircore system, and retrieving the data for off- 
system archival* Figure 110 shows the hierarchy of windows used for call record 
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management. The hierarchy 3500 includes the call record manager window 3501 , 
archive window 3502, configuration window 3503, and hilling window 3504. The 
billing window 3504, and associated lower level windows, are only available if the 
prepaid wireless package is configured. Associated with the configuration window 
3503 are output selection window 3507 and auto removal window 3508. Associated 
with the billing window 3504 is distributor selection window 3506 and bill generation 
window 3509. The call record manager window 3501 provides operator access to 

8 view, process or redirect call detail record outputs on the aircore system. 

9 Figure 1 1 1 shows the archive window 3502. The archive window 3502 allows 
the operator to view and direct archived output of call detail records that have been 

1 1 created on the aircore system. 

12 Figure 1 12 shows a configuration window 3503. The configuration window 

13 3503 allows the operator to determine the real time output destination for call detail 

14 records. Regardless of the output type selected, a file containing the call records on 

15 disk is always created. In addition, the operator has the ability to configure the auto 

16 removal period for the call detail records. Using the output selection window 3507, 

17 the operator can send an output to a display or a printer, for example. 

18 Figure 1 13 shows the auto removal window 3508. Using the auto removal 

19 window 3508, the operator can set the number of days that the call detail record will 

20 be archived on the system. The number of days the call detail records are stored on 

21 the aircore system before automatic removal can be set a value between 1 and 1 80 in 

22 increments of one day. 

23 ^ aircore platform 200 can provide, as an option, fully integrated prepaid 

24 functionality. This functionality can span across both wireless and wireline 

25 applications providing a seamless prepaid system. Furthermore, this functionality is 

26 provided as an integrated software feature, saving the cost and maintenance of a 

27 separate off-board prepaid system. The prepaid system feature package provides full 

28 functional real time debiting for aircore customers complete with a full billing 

29 package and a comprehensive rating schedule. Figure 1 14 shows the rating 
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1 administration window hierarchy 3600 that is used in conjunction with the aircore 

2 prepaid system. A database management icon screen 3601 is shown initially. Next, a 

3 rating administration window 3602 is displayed. A distributor data window 3603 and 

4 a distributor properties window 3606 can be selected from the rating administration 

5 window 3602. Finally, from the distributor data window 3603, an add/modify/delete 

6 rate window 3605 can be accessed as well as individual rate plans 0-9 360 t . n with 

7 associated add/modify delete rate windows 3607 i_ n . The aircore prepaid system 

8 accommodates ten rate plans. 

9 Figure 115 shows the rating administration window 3602. 

10 Figure 116 shows the add/modified/delete rate window 3605. A distributor 

1 1 number box 3621 shows the number assigned to a distributor when added to the 

12 system. A default rate plan box 3622 shows the rate plan used as the default for 

13 subscribers added for the distribution shown in the distributor number box 3621. The 

14 default rate plan is used when a rate plan is not explicitly assigned. A description 

15 window 3623 provides the name and/or a description of the distributor shown in the 

1 6 distributor number box 362 1 . 

17 Figure 1 17 shows distributor data modification window 3603. The distributor 

18 data modification window 3603 allows for the configuration of the land charges rate 

19 plans used for real time billing on the aircore system. The window 3603 is accessed 

20 on a per distributor basis. Distributor data includes access to land charges and 

21 configured access to rate plans. In addition to a default rate plan, each distributor can 

22 have up to ten different rate plans. Each rate plan specify specific air time rating 

23 structures. Land charges are specified on a per distributor basis. 

24 Figure 118 shows a rate plan window 3607. From the distributor data 

25 modification window 3603 shown in Figure 1 17, if an active rate plan button is 

26 selected, the rate plan window 3607 appears. The rate plan window 3607 provides the 

27 operator with the ability to configure the air time charges associated with a specific 

28 rate plan. The rate plan window 3607 also provides the ability to specify any 

29 exceptions to the main distributor land based charges. Data specified in the rate plan 
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window 3607 overrides the date in the distributor window 3603 and allows an 
operator to specify unique plans for both land and air time rates without adding a new 



1 
2 

3 distributor each time. 

4 Figure 1 19 shows a country entry window 3640. The country entry window 

5 3640 allows modification of rates charges for the land portion of the call. These 

6 charges are based on a first and additional minute rate to each location around the 

7 world. 

8 Figure 120 shows a debit subscriber profile window 3650. The debit 

9 subscriber profile window 3650 is used to input debit specific subscriber data for 

0 accounts. The window 3650 is accessed via the debit button on a main subscriber 

1 profile window (not shown). The fields of the window 3650 specify the parameters 

2 used for real time billing and account information for the subscriber. The window 

3 3650 opens as an overlay on the subscriber profile window and allows the subscriber 

4 number, name, customer group and serial numbers to be viewed when editing the 

5 debit subscriber profile window 3650. A balance section 365 1 includes the current 

6 amount, which is the current balance in dollars for the individual subscriber account. 

7 This amount is incremented based on the subscriber usage. Subscriber access is cutoff 

8 when the current amount is equal to the credit limit. The credit limit is the maximum 

9 amount in dollars for the subscriber account. The credit limit is compared against the 

0 current amount value to determine if access to the account is allowed. If the current 

1 amount field equals the credit limit field, access to the account is not allowed. The 

2 payment method field specifies the method of payment for the account. The payment 

3 method can be cash, credit or other. If credit chosen, the credit card fields must be 

4 filled in. The debit subscriber profile window 3650 also includes a credit card section 

5 3652. The credit card section 3652 includes the credit card number (if applicable) the 

6 type of credit card and the expiration date of the credit card. Other information 

7 provided in the debit subscriber profile window 3650 includes the distributor and rate 

8 plan and billing methods chosen for this customer. 
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1 The billing window 3504 (see Figure 1 10) provides access to customer billing 

2 records. The billing window 3504 is accessed from the menu bar of the call record 

3 manager window 3501. When selected, the distributor selection window 3506 shown 

4 in Figure 21 is displayed. The distributor selection window 3506 allows an operator 

5 to select a distributor for a billing calculation. The distributor selection window 3506 

6 provides access to the billing generation window 3509. 

7 The aircore system provides for the configuration of up to twenty different 

8 language files for assignment to customers or for announcements. Figure 123 shows a 

9 languages administration window 3680. The languages administration window 3680 

10 provides operator access to a language configuration database in the aircore system. 

1 1 The language configuration window 3680 is accessed from the database management 

12 icon screen 3101 (see Figure 90). 

13 Figure 122 shows the billing generation window 3509. The billing generation 

14 window 3509 allows access to individual subscriber bills and invoices as well as 

15 location summaries of customer usage. Billing information is accessed on the basis of 

16 the location summoned. 

17 While this invention has been described in conjunction with the specific 

18 embodiment outlined above, it is evident that many alterations, modifications and 

19 variations will be apparent to those skilled in the art. Accordingly, the preferred 

20 embodiments of the invention as set forth above are intended to be illustrative, not 

21 limiting. Various changes may be made without departing from the spirit and scope 

22 of the invention as defined in the following claims. 
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1 In the Claims; 

2 1 . A switching center for a communications system that provides 

3 communications services to customers having wireless and other communications 

4 devices, comprising: 

5 a first interface, the first interface receiving and sending digital messaging 

6 having a first protocol; 

7 a second interface, the second interface receiving and sending digital 

8 messaging having a second protocol; and 

9 a processor system coupled to the first and the second interfaces, wherein the 

10 processor system controls operation of the first and the second interfaces and 

1 1 generates control messages for sending by the first and the second interfaces. 

12 2. The switching center of claim 1 , wherein the first interfaces comprises: 

13 a first intrasystem message handler; and 

14 a first intersystem message handler, and wherein the second interface 

15 comprises: 

16 a second intrasystem message handler; and 

17 a second intersystem message handler. 

1 8 3 - The switching center of claim 2, wherein the first intrasystem message handler 

19 operates according to IS-634 protocols, the second intrasystem and intersystem 

20 message handlers operate according to GSM protocols, and the first intersystem 

21 message handler operates according to IS-41 protocols. 

22 4. The switching center of claim 3, wherein the GSM protocols include GSM A 

23 (Series 4 and 8) protocols, IS-651 and J-STD protocols, IS-652 protocols and GSM 

24 09.02 protocols. 

25 5. The switching center of claim 3, wherein the IS-634 and the B-41 protocols 

26 include time division multiple access (TDMA) protocols and code division multiple 

27 access (CDMA) protocols and AMPS protocols. * 
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1 6. The switching center of claim 1, wherein the first interface further receives and 

2 sends analog messaging, the analog messaging including Advanced Mobile Telephone 

3 System (AMPS) protocols. 

4 7. The switching center of claim 6, wherein the AMPS protocols include IS-634 

5 protocols and ISDN PRI+ protocols and proprietary protocols. 

6 8. The switching center of claim 1 , further comprising: 

7 a home location register coupled to the processor system; and 

8 a visitor location register coupled to the home location register and the 



processor system, wherein the home location register stores permanent data related to 
customers of the communications system that are homed on the communications 
system, and wherein the visitor location register stores temporary data related to 
customers that are active on the communications system, the home location register 
and the visitor location register indicating a most recent protocol used by a wireless 
communications device of a customer and indicating other protocols useable by the 



15 wireless communications device. 

16 9. The switching center of claim 8, wherein the permanent data related to 

17 customers in the home location register is stored in a customer profile, the customer 

18 profile including one or more of call features, call restrictions, mobile unit protocols, 

19 line identification, personal identification number, call offering, prepaid services and 

20 customer information. 

21 10. The switching center of claim 8, wherein the home location register includes a 

22 common data section and protocol-specific data sections, wherein the common data 

23 section stores data generic to all protocols and the protocol-specific data sections 

24 stores data unique to one or more specific protocols. 

25 11. The switching center of claim 8, wherein the processor system determines a 

26 protocol of a wireless communications device by reference to one of the home 
. 27 location register and the visitor location register. 

28 12. The switching center of claim 1, wherein the communications system includes 



one or more base stations, and wherein the processor system determines a protocol of 
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1 a wireless communications device based on a protocol of the base station that 

2 communicates between the switching center and the wireless communications device. 

3 13. The switching center of claim 1 , wherein the communications system includes 

4 a multi-protocol base station, the multi-protocol base station sending base station 

5 control messages to the switching center, and wherein the processor system 

6 determines a protocol of a wireless communications device by interpreting protocol 

7 data contained in the base station control message. 

8 14. The switching center of claim 1, wherein the communications system receives 

9 communications from an external wireless system having an external home location 

10 register and an external communications device registered on the external home 

1 1 location register, and wherein the processor system determines a protocol of the 

12 external communications device by obtaining an identification of the external home 

1 3 location register. 

14 15. The switching center of claim 1 , wherein the processor system generates and 

15 interprets generic command messages, the generic command messages operable to 

16 control the communications services according to at least the first and the second 

17 protocols. 

18 16. The switching center of claim 1 , wherein the processor system generates and 

19 interprets protocol-specific command messages, the protocol-specific command 

20 messages used to provide additional control of the communications services. 

21 17. The switching center of claim 1, further comprising an asynchronous transfer 

22 mode (ATM) interface, the ATM interface providing wireless ATM communications 

23 and other packet board communications. 

24 18. The switching center of claim 1, further comprising a public switched 

25 telephone network (PSTN) interface. 

26 19. The switching center of claim 1, further comprising a private branch exchange 

27 (PBX) interface. 
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1 20. The switching center of claim 1 , wherein the wireless communications devices 

2 include a fixed wireless telephone, a mobile telephone and a computer having a 

3 wireless modem. 

4 21. The switching center of claim 1 , further comprising: 

5 an equipment identification register, wherein the equipment identification 

6 register includes serial number data related to the mobile communications devices that 

7 are homed on the wireless communications system; and 

8 an authentication center, wherein the authentication center provides 

9 authentication and encryption parameters for wireless communications received at and 

10 originated from the switching center. 

1 1 22. The switching center of claim 1 , further comprising: 

12 a first device handler coupled to the first interface; and 

13 a second device handler coupled to the second interface, wherein the first and 

14 the second device handlers are operable to receive and transmit multi-protocol 

15 messaging from and to devices external to the switching center and to transmit and 

16 receive generic messaging to and from the first and the second interfaces, respectively. 

17 23. The switching center of claim 1, wherein the processing system comprises: 

18 a central processor, the central processor controlling operation of the processor 

19 system; 

20 an authentication and registration system, the authentication and registration 

21 system controlling registration of the wireless communications devices with the 

22 communications system and providing encryption and ciphering of voice and data 

23 communications; 

24 a paging system, the paging system sending paging messages to the wireless 

25 communications devices and receiving page response messages from the wireless 

26 communications devices; 

27 a timer system, the timer system setting timers in response to operations of the 

28 processing system; 
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1 a recovery and startup system, the recovery and startup system managing a 

2 status of communications trunks in the communications system and performing audits 

3 of the communications system; and 

4 a memory, wherein the memory stores information related to a particular call 

5 in a memory area, and wherein components of the processor system access the 

6 memory area to retrieve and store information related to the particular call. 

7 24. The switching center of claim 23, wherein the processor system further 

8 comprises a hand off processor, the hand off processor receiving and processing hand 

9 off requests from a wireless communications device in the communications system, 

10 determining a target base station for hand off and sending a hand off command to the 

1 1 wireless communications device. 

12 25. The switching center of claim 23, wherein the processor system operates to 

13 reserve a voice channel with each base station in the communications system that is 

14 capable of receiving communications from the wireless communications device, and 

15 wherein the processor system operates to release all base stations having a reserved 

16 voice channel, except the target base station, upon receipt by the processor system of a 

17 call connect acknowledge message. 

1 8 26. The switching center of claim 1 , further comprising a graphical user interface, 

19 the graphical user interface providing an operator access to operate the switching 

20 center and to update data related to the customers, database configuration, system 

21 configuration and maintenance. 

22 27. A mobile switching center, comprising: 

23 a central processor that processes incoming signals, wherein the incoming 

24 signals are switched in a telecommunications network; and 

25 a wireless interface module that supports two or more wireless protocols. 

26 28. The mobile switching center of claim 27, further comprising a switch 

27 management module that manages the switching of the incoming signals. 

28 29. The mobile switching center of claim 27, wherein the wireless interface 

29 module comprises a digital interface that supports digital wireless communications. 
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1 41. The mobile switching center of claim 27, further comprising an equipment 

2 identification register which stores information identifying equipment used with the 

3 mobile switching center. 

4 42. The mobile switching center of claim 27, further comprising a prepaid module 

5 that enables prepaid communication. 

6 43. The mobile switching center of claim 27, further comprising a features module 

7 that supports a plurality of communication features. 

8 44. The mobile switching center of claim 27, further comprising a remote network 

9 management access module that is remotely located from and operably connected to 

10 the mobile switching center. 

1 1 45. The mobile switching center of claim 27, further comprising an authentication 

12 center that authenticates incoming signals. 

13 46. An advanced intelligent message handler for use in a mobile 

14 telecommunications network having mobile communications devices and one or more 

15 base stations, the advanced intelligent message handler, comprising: 

16 a first interface for intersystem messaging, the first interface, comprising: 

17 a first GSM processing thread, 

18 a first TDMA processing thread, 

19 a first CDMA processing thread, and 

20 a first AMPS processing thread; 

21 a second interface for intrasystem messaging, the second interface, comprising: 

22 a second GSM processing thread, 

23 a second TDMA processing thread, 

24 a second CDMA processing thread, and 

25 a second AMPS processing, thread; and . 

26 a processor system coupled to the first and the second interfaces, the processor 

27 system controlling a flow of message traffic to and from the first and the second 

28 interfaces. 
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1 30. The mobile switching center of claim 27, wherein the wireless interface 

2 module comprises an analog interface that supports analog wireless communications. 

3 31. The mobile switching center of claim 27, wherein the wireless interface 

4 module comprises a GSM interface that supports GSM protocol wireless 

5 communications. 

6 32. The mobile switching center of claim 27, wherein the wireless interface 

7 module comprises a TDMA interface that supports TDMA protocol wireless 

8 communications. 

9 33. The mobile switching center of claim 27, wherein the wireless interface 

10 module comprises a CDMA interface that supports CDMA protocol wireless 

1 1 communications. 

12 34. The mobile switching center of claim 27, wherein the wireless interface 

13 module comprises a AMPS interface that supports AMPS protocol wireless 

14 communications. 

15 35. The mobile switching center of claim 27, wherein the wireless interface 

16 module comprises a DAMPS interface that supports DAMPS protocol wireless 

17 communications. 

18 36. The mobile switching center of claim 27, further comprising a visitor location 

19 register that stores information about visiting switch users. 

20 37. The mobile switching center of claim 27, further comprising a home location 

21 register that stores information about home switch users. 

22 38 - The mobile switching center of claim 27, further comprising a wired interface 

23 module that provides connections to wired land-lines. 

24 39. The mobile switching center of claim 27, further comprising a graphical user 

25 interface that allows an operator to operate the mobile switching center. 

26 40. The mobile switching center of claim 39, wherein the graphical user interface 

27 is remotely located from the mobile switching center. 
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1 customer profile indicating protocols available to the mobile and a most recent 

2 protocol used by the mobile unit; and 

3 creating a visitor location register, the visitor location register containing the 

4 customer profile for each mobile unit that is active in the multi-protocol wireless 

5 network. 

6 55. The method of claim 54, wherein the customer profile further includes call 

7 features, call restriction, line identification, personal identification number, call 

8 offering and prepaid services. 

9 56. The method of claim 54, wherein the home location register includes a 

10 common data section and a protocol-specific data section, the common data section 

1 1 storing data generic to all protocols and the protocol-specific data sections storing data 

12 unique to one or more protocols. 

13 57. The method of claim 54, further comprising determining a protocol of a 

14 wireless communications device by reference to one of the home location register and 

15 the visitor location register. 

16 58. The method of claim 47, furmer comprismg deteimining a protocol of a 

17 wireless communications device by reference to a protocol of a base station that 

18 communicates with the switching center. 

19 59. The method of claim 47, wherein the multi-protocol wireless network includes 

20 one or more multi-protocol base stations, wherein the processor determines a protocol 

21 of a wireless communications device by interpreting protocol data contained in 

22 communications from the one or more multi-protocol base stations. 

23 60. The method of claim 47, further comprising: 

24 receiving communications from an external communications device from a 

25 wireless network external to the multi-protocol wireless network, the external wireless 

26 network including an external home location register; and 

27 deteimining a protocol of the external communications device by obtaining an 

28 identification of the external home location register. 
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1 47. A method for controlling communications in a multi-protocol wireless 

2 network, comprising: 

3 receiving first digital communications according to a first protocol at a first 

4 interface; 

5 sending a first control message according to the first protocol; 

6 receiving second digital communications according to a second protocol at a 

7 second interface; and 

8 sending a second control message according to the second protocol, wherein a 

9 processor in a switching center interprets the first and the second digital 

10 communications and generates the first and the second control messages. 

1 1 48. The method of claim 47, further comprising; 

12 receiving intrasystem communications at a intrasystem message handler; and 

13 receiving intersystem communications at a intersystem message handler. 

14 49. The method of claim 48, wherein the intrasystem message handler operates 

15 according to IS-634 and GSM standards and the intersystem message handler operates 

16 according to IS^tl and GSM standards. 

17 50. The method of claim 49, wherein the GSM protocols include GSM A 

18 protocols, IS-65 1 protocols, IS-652 protocols and GSM 09.02 protocols. 

19 51. The method of claim 49, wherein the IS-634 and IS-4 1 protocols include time 

20 division multiple access (TDMA) protocols and code division multiple access 

21 (CDMA) protocols and AMP protocols. 

22 52. The method of claim 47, wherein the first interface further receives and sends 

23 analog communications, the analog communications including Advanced Mobile 

24 Telephone System (AMPS) protocols. 

25 53. The method of claim 52, wherein the AMPS protocols include IS-634 

26 protocols and ISDN PRI+ protocols and proprietary protocols. 

27 54. The method of claim 47, further comprising: 

28 creating a home location register, the home location register including a 

29 customer profile for each mobile unit in the multi-protocol wireless network, the 
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1 sending and receiving registration notification messages to register a mobile 

2 unit in a visitor location register; 

3 sending and receiving paging messages to access a mobile unit in the multi- 

4 protocol wireless network; 

5 setting a timer to time out control messages; 

6 maintaining a status of communications trunks in the multi-protocol wireless 

7 network; and 

8 storing data related to a particular call in a common memory area, the data for 

9 the particular call used by components of the multi-purpose wireless network to 

10 control and access the particular call. 

1 1 72. The method of claim 47, further comprising; 

12 monitoring a signal strength of communications with a mobile 

13 communications device; 

14 sending a hand off request when the signal strength exceed a limit; 

15 measuring signal-strengths of each of the other base stations in the multi- 

16 protocol wireless network; 

17 reserving a voice channel in each of the other base stations; and 

18 selecting a target base station for communication with the mobile 

19 communications device; and 

20 handing off the mobile communications based on the measurements. 

21 73. The method of claim 47, further comprising providing a graphical user 

22 interface to the switching center, the graphical user interface allowing an operator to 

23 update information stored by the switching center. 

24 74. The method of claim 47, further comprising; 

25 designating a first communications trunk, the first communications trunk 

26 carrying the first control message, wherein the first communications trunk connects a 

27 first base station and the switching center; and 
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1 61. The method of claim 47, wherein the processor generates and interprets 

2 generic messages, the generic messages providing generic control signals to control 

3 operation of the multi-protocol wireless network. 

4 62. The method of claim 47, wherein the processor generates and interprets 

5 protocol-specific messages, the protocol-specific messages providing additional 

6 control of the communications devices. 

7 63. The method of claim 47, further comprising providing packet based 

8 communications. 

9 64. The method of claim 63, further comprising providing an asynchronous 

10 transfer mode (ATM) interface providing wireless ATM communications. 

1 1 65. The method of claim 64, wherein the ATM interface provides PSTN 

12 connectivity and an extension of a switch matrix. 

13 66. The method of claim 47, further comprising connecting the switching center to 

14 a public switched telephone network (PSTN). 

15 67. The method of claim 47, further comprising connecting the switching center to 

16 a private branch exchange. 

17 68. The method of claim 47, wherein the communications devices include a fixed 

18 wireless telephone, a mobile telephone and a computer having a wireless modem. 

19 69. The method of claim 47, further comprising: 

20 recording an identity of a mobile device; and 

21 encrypting and decrypting the first and the second digital communications. 

22 70. The method of claim 47, further comprising: 

23 receiving first communications at and sending first communications from a 

24 first device handler coupled to the first interface; and 

25 receiving second communications at and sending second communications 

26 from a second device handler coupled to the second interface, wherein the first and the 

27 second device handlers are operable to receive and transmit multi-protocol 

28 communications. 

29 71. The method of claim 47, further comprising: 
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1 designating a second communications trunk, the second communications trunk 

2 carrying the second control message, wherein the second communications trunk 

3 connects a second base station and the switching center. 

4 75. The method of claim 47, wherein the switching center comprises a plurality of 

5 communications trunks, the switching center designating one or more of the plurality 

6 of the communications trunks for use in connecting wireless calls. 

7 76. The method of claim 75, wherein the switching center tracks a state of each 

8 communications trunk of the plurality of communications trunks. 

9 77. The method of claim 76, wherein a state of a communications trunk may be 

10 one of not configured, blocked, unblocked, unblocked pending, call processing, 

1 1 blocked pending and maintenance. 

12 78. The method of claim 77, wherein the communications trunk transitions from 

13 the not configured state to the blocked state when a base station is activated in the 

14 wireless network. 

15 79. The method of claim 77, wherein the communications trunk transitions from 

16 the blocked state to the unblocked pending state based on a recovery request. 

17 80. The method of claim 77, wherein the communications trunk transitions from 

18 the unblocked state to the call processing state when a base station is allocated for call 

19 processing. 

20 81. The method of claim 47, further comprising: 

21 receiving a call from a prepaid customer; 

22 processing the call from the prepaid customer; 

23 determining an allowed time of call based on a prepaid account for the prepaid 

24 customer, 

25 determining a warning time for the call, wherein the warning time is a time 

26 less than the allowed time; 

27 connecting the call; 

28 monitoring a time of the call; 
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1 providing a warning to the prepaid customer when the warning time occurs; 

2 and 

3 disconnecting the call when the allowed time is reached. 

4 82. The method of claim 81, further comprising 

5 providing a plurality of rate plans, wherein the prepaid customer may select a 

6 desired rate plan from the plurality of rate plans. 

7 83. The method of claim 82, wherein the desired rate plan is stored in a home 

8 location register. 

9 84. The method of claim 81, further comprising 

10 determining a least cost route for the call from the prepaid customer. 

11 85. The method of claim 81, further comprising: 

12 at a completion of the call from the prepaid customer, computing an actual 

13 cost for the call; and 

14 updating the prepaid account, based on the actual cost for the call. 

15 86. A graphical user interface (GUI) for use with a scalable, wireless switching 

16 center, comprising: 

17 a home location register (HLR) GUI hierarchy; 

18 a visitor location register (VLR) GUI hierarchy; 

19 a database management GUI hierarchy; 

20 a system configuration GUI hierarchy; and 

21 a cal1 record manager GUI hierarchy, wherein GUIs provide access to data that 

22 controls operation of the switching center. 

23 87. The GUI of claim 86, further comprising a rate plan hierarchy GUI. 

24 88. The GUI of claim 86, wherein the HLR GUI hierarchy comprises: 

25 a password GUI; 

26 a HLR access GUI; and 

27 protocol-specific HLR GUIs, wherein the HLR access GUI lists subscribers to 

28 a network serviced by the switching center. 
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1 89. The GUI of claim 88, wherein the protocol-specific HLR GUIs include one of 

2 GSM, CDMA TDMA, AMPS, multiple-protocol and prepaid. 

3 90. The GUI of claim 88, wherein the protocol-specific HLR GUIs comprise a 

4 subscriber profile GUI. 

5 91. The GUI of claim 90, wherein the subscriber profile GUI includes: 

6 a subscriber definition window; 

7 a call offering window; 

8 a protocol window; 

9 a call restriction window; 

10 a call feature window; 

11 a line identification window; and 

12 an add, modify, delete window that allows a subscriber's profile to be updated. 

13 92. The GUI of claim 86, wherein the VLR GUI hierarchy comprises: 

14 a password GUI; 

15 a VLR access GUI; and 

16 protocol-specific VLR GUIs, wherein the VLR access GUI lists subscribers 

17 active on a network serviced by the switching center. 

18 93. The GUI of claim 82, wherein the protocol-specific VLR GUIs include one of 

19 GSM, CDMA, TDMA, AMPS, multiple-protocol and prepaid. 

20 94. The GUI of claim 92, wherein the protocol-specific VLR GUIs comprise a 

2 1 subscriber profile GUI. 

22 95. The GUI of claim 94, wherein the subscriber profile GUI includes: 

23 a subscriber definition window; 

24 a call offering window; 

25 a protocol window; 

26 a call restriction window; 

27 a call feature window; 

28 a line identification window; 

29 a call feature window; and 
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1 an add, modify, delete window that allows a subscriber profile to be updated. 

2 96. the GUI of claim 86, wherein the system configuration GUI hierarchy, 

3 comprises: 

4 a trunk maintenance GUI, the trunk maintenance GUI including: 

5 a span and channel selection, and 

6 a change channel state selection. 

7 97. The GUI of claim 86, wherein the system configuration GUI hierarchy, 

8 comprises: 

9 a board configuration including a modify module that allows a board to be 

10 reconfigured. 

11 98 - The GUI of claim 97, wherein the board includes one of a T- 1/E- 1 board, a 

12 voice I/O board, a conference board and a SS-7 board. 

13 99. The GUI of claim 86, wherein the call record GUI includes an archived data 

14 window. 

15 100. The GUI of claim 86, wherein the call record GUI includes an output selection 

16 GUI, the output selection GUI providing one of a display selection, a printer selection, 

17 no selection and other output selection. 

18 10L The GUI of claim 86, wherein the call record GUI includes an auto-removal 

19 GUI, the auto-removal GUI including a number of days before removing archived 

20 files selection. 

21 102. The GUI of claim 87, wherein the rate plan hierarchy GUI, comprises: 

22 a rating administration tab, the rating administration tab displaying a list of 

23 distributors; 

2 4 a distributor data GUI; 

25 a modify distributor data GUI; and 

26 a modify rate plan GUI. 

27 103. The GUI of claim 102, wherein the rate plan hierarchy GUI further comprises 

28 a modify prepaid entry GUI. 

29 104. The GUI of claim 103, wherein the prepaid entry GUI, comprises: 
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a balance window; 

a rate information window; 

a payment method window; and 

an other features window. 
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MULTI-PROTOCOL WIRELESS COMMUNICATION 
APPARATUS AND METHOD 

Field Of The Invention 

The invention is directed to a wireless communications apparatus and method. 
In particular, the invention is directed to a multi-protocol, scaleable wireless switching 
platform and method. 
Background 

Wireless communications in the United States were initially conducted solely 
through analog systems and protocols. The most prevalent analog protocol remains 
the Advanced Mobile Telephone System (AMPS) protocol. To handle wireless 
communications and to allow interconnection with traditional wired land-lines, 
switching systems and base stations were required. The analog switching systems are 
large and are designed to cover large markets and handle large volumes of calls. 

In the 1990's digital systems and protocols began to be used for wireless 
communications. Examples of digital protocols are the Global System for Mobile 
Communication (GSM) code division multiple access (CDMA), and time division 
multiple access (TDMA). When wireless networks began to switch to digital 
protocols, they could not simply upgrade their analog base stations to digital. New 
equipment for the digital facilities was required. However, the networks continued to 
use large switching systems designed to cover their large spread markets. Examples 
of large switching systems are AT&T's 5ESS® system and the AXE system made by 
Ericsson. The 5ESS® switch is described in detail in the AT&T Technical Journal, 
Vol. 64, No. 6, part 2, July/August 1985, pages 1305-1564. - 

Large switching systems are designed to cover large markets and to handle 
many thousands of customers. The larger systems have the advantage of being able to 
provide a wide range of call options, such as call forwarding, caller identification and 
call waiting. The switching systems are expensive, however and, therefore, may not 
be appropriate for small markets and wireless providers. Additionally, large switching 
systems can be inefficient because of the added additional cost for increased back 
hauls of calls. 



WO 00/46938 



PCT/USOO/02797 



Typical switching systems employ proprietary architectures that use hardware 
components for switching, external interfaces, operating system, and control. 
Summary Of The Invention 

A multi-protocol mobile switching center (MSC) provides wireless 
communications for mobile devices operating on a local wireless network according 
to any standard protocol including those of the Global Systems for Mobile 
Communications (GSM) standards and IS-41 standards (including time division 
multiple access (TDMA), code division multiple access (CDMA), and Advanced 
Mobile Telephone System (AMPS)). The MSC may be incorporated onto a single 
platform having a home location register (HLR) and an authentication center (AC or 
AuC), as well as a visitor location register (VLR) and an equipment identity register 
(EIR). 

The multi-protocol MSC is scalable so that it may be used for a small number 
of customers, such as in a rural setting to provide telephone access, or as part of an in- 
building communications network. The scalable, multi-protocol MSC may also be 
used to construct a large, distributed wireless network. Thus, the scalable, multi- 
protocol MSC provides the flexibility to be used with a wide range of customer bases, 
and within a variety of different typographies. 

Because the MSC can process wired and wireless calls according to any 
protocol, a single switching center may serve customers who operate mobile and fixed 
communications devices, regardless of protocol. This true multi-protocol 
functionality makes this switching solution extremely efficient and cost effective, and 
eliminates the need for separate, protocol-specific components. 

The multi-protocol MSC can be housed in a standard chassis. The multi- 
protocol MSC can use standard, off the shelf hardware for most data storage and 
processing functions. The multi-protocol MSC can be easily updated to take 
advantage of industry advances by simply replacing select components in the chassis. 

The multi-protocol MSC provides full-featured telephone and data services, 
including wired and wireless analog and digital telephony, conference calling, prepaid 
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1 calling, emergency call routing and long-distance resale. The multi-protocol MSC 

2 also provides pocket switching applications such as asynchronous transfer mode 

3 (ATM). 

4 The multi-protocol MSC incorporates advanced graphical user interfaces 

5 (GUIs) that display system data in a convenient, easy to access format. A system 

6 operator can quickly select data for display, and can easily modify selected data 

7 entries. The system operator can control operation of the multi-protocol MSC using 

8 the intuitively structured GUIs, 

9 The multi-protocol MSC may incorporate a number of sophisticated features 

10 in addition to the HLR, VLR, EIR and the authentication center. These features 

1 1 include an operations and maintenance center, wire line and tandeming services, and 

12 hot (real-time) billing and prepaid services. 

13 When used for distributed switching, the multi-protocol MSC may reduce 

14 build out and operational costs associated with large switching centers. This 

15 architecture also eliminates needless back hauling by switching local calls locally. 

16 Finally, the architecture allows for add on as a wireless customer base expands. 

17 The multi-protocol MSC includes a first interface that receives digital and 

18 analog communication according to a first protocol and a second interface that 

19 receives digital communication according to a second protocol. The first and the 

20 second interfaces include inter system (system-to-system) message handlers and 

21 intra system (within system) message handlers. 

22 The hardware and software architecture of the MSC is designed to use generic 

23 signaling as much as possible to provide call connection and other functions. 

24 Protocol-specific communications are handled at a device handler (lower) level, and 

25 higher level processing uses generic messaging. A table may be used to map 

26 messages of the different protocols to the generic messages used by the MSC. The 

27 hardware of the aircore system is based on off-the-shelf industry standard components 

28 for each of the four areas typically found as proprietary in current systems. The use of 

-3- 
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off-the-shelf standardized switching components, interface boards, operating system 
and control processing provide a unique evolution path for the aircore system. 

The HLR and VLR are structured so that data that does not depend on a 
specific protocol is stored in a common memory portion while protocol-specific data 
is stored in protocol specific portions of the HLR and VLR. This logical arrangement 
of the HLR and VLR provides for quick access to data by components of the MSC 
and allows for easier updating by a system operator. 

An advanced intelligent message (AIM) handler interfaces with the VLR and 
the HLR to determine the current location and identification of mobile units homed on 
the HLR or roaming in the local wireless network. The AIM also determines the 
protocol applicable for the mobile unit. For calls received at the MSC from a local 
wireless network base station, the protocol determination may be made by reference to 
the protocol of the base station. For multi-protocol base stations, the determination 
includes decoding information provided in the service request or similar message sent 
by the base station. For other mobile units, the MSC may communicate with external 
wireless components such as other HLRs, VLRs, and MSCs. 

The MSC includes an authentication and registration system that controls 
registration of mobile communications devices operating on the system controlled by 
the MSC. The authentication and registration system also provides encryption and 
ciphering of voice and data communications. 

The MSC can also be used as an adjunct to a private branch exchange (PBX) 
to create an in-building wireless network. Used as such, the MSC and HLR can be 
used to route calls preferentially among mobile units and fixed telephones and other 
communications devices. 
Brief Description Of The Drawings 

The invention will be described in conjunction with the following figures, in 
which like numbers refer to like features, and wherein 

Figures la - Id show wireless communication environments according to the 
invention. 
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1 Figure 2 is a block diagram of an aircore switching platform. 

2 Figure 3 shows a wireless loop architecture. 

3 Figure 4 shows a fixed wireless loop architecture. 

4 Figure 5 shows the aircore platform with local area mobility. 

5 Figure 6 shows the aircore platform with system level mobility. 

6 Figure 7 shows the aircore platform with full scale mobility. 

7 Figure 8 shows a wireless network architecture. 

8 Figure 9 is a block diagram of aircore functions. 

9 Figures 10 is a block diagram of the aircore software architecture, 

1° Figure 1 1 is a block diagram of the advanced intelligent message handler 

11 architecture. 

12 Figure 12 is a block diagram of the A-interface message handler. 

13 Figure 13 is a block diagram of the ISDN user part message handler. 

14 Figure 14 is a block diagram of a intersystem message handler. 

15 Figure 15 is a block diagram of a device handler for voice input-output 

16 devices. 

1 7 Figure 1 6 is a block diagram of a device handler for digital interfaces. 

18 Figure 17 is a block diagram of a device handler for ISDN interfaces. 

19 Figure 1 8 is a block diagram of a device handler for signaling system 7 

20 communication. 

2 1 Figure 19 is a block diagram showing software interlayer communications. 

22 Figure 20 is a logical representation of the home location register. 

23 Figure 21 illustrates the HLR/VLR database structures. 

24 Figure 22 is a block diagram illustrating the location management feature of 

25 the visitor location register. 

26 Figure 23 is a state machine for mobile originated call processing. 

27 Figure 24 is a state machine for PSTN originated call processing* 

28 Figure 25 is a state machine for mobile terminated call processing. 

29 Figure 26 is a diagram of a near end facility state machine. 
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1 


Figures 27 is a diagram of a far end facility state machine. 


2 


Figure 28 is a diagram illustrating mobile unit hand off. 


3 


Figure 29a shows the software components used for call processing. 


4 


Figure 29b shows the object structure for the aircore call processine 


5 


Figure 29c is a flow chart illustrating an authentication process. 


6 


Figures 30-34 are flow charts showing message signaling associated with 


7 


interface maintenance. 


8 


Figures 35-40 are flow charts showing message signaling associated with trunk 


9 


management. 


10 


Figures 41-47 are flow charts showing message signaling associated with 


11 


mobility management. 


12 


Figures 48-66 are flow charts showing message signaling for call processing. 


13 


Figures 67-71 are flow charts showing message signaling associated with call 


14 


processing with an external HLR. 


15 


Figures 72 is a flow chart showing message signaling associated with hand off 


16 


pre-processing. 


17 


Figure 73 is a logical diagram of a prepaid rating system. 


18 


Figure 74 is a flow diagram illustrating emergency call processing. 


19 


Figure 75 is a block diagram illustrating first party call control. 


20 


Figure 76 is a block diagram illustrating third party call control. 


21 


Figures 77-79 are block diagrams of call delivery methods using third party 


22 


call control. 


23 


Figure 80 is a block diagram of an in-building wireless communications 


24 


network. 


25 


Figures 8 1-84 are block diagrams of an embodiment of the aircore platform 


26 


hardware architecture. 


27 


Figures 85-86 are block diagrams of another embodiment of the aircore 


28 


platform hardware architecture. 
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Figures 87-123 illustrate graphic user interface screens for use with the aircore 
platform. 

Detailed Description Of The Invention 

Mobile telecommunications (radio) systems that permit customer calling from 
mobile stations such as automobiles, or small light weight hand held personal 
communications units are becoming increasingly prevalent. These systems use the 
principles of cellular technology to allow the same frequencies of a common 
allocating radio bandwidth to be reused in separated local areas or cells of a broader 
region. Each cell is served by a base transceiver station comprising a group of local 
transceivers connected to a common antenna. Base station systems, each including a 
controller and one or more transceiver stations, are interconnected via a switching 
system, called a mobile switching center (MSC), which is also connected to the public 
switched telephone network (PSTN), and the Public Land Mobile Telephone Network 
(PLMN). These mobile telecommunications systems are now entering a second 
generation characterized by digital radio communications with a different set of 
standards, such as the European Global System for Mobile Communications (GSM) 
standard promulgated by the Special Mobile Group (SMG). The GSM standard is 
also being adapted for use in the United States. In addition, in the United States, 
CDMA, TDMA, DAMPS, and AMPS are used for digital cellular mobile 
communications. 

The mobile telecommunications systems have many components that need to 
communicate signaling information for controlling the establishment of connections. 
Such signaling information is communicated over channels that are separated from the 
channels carrying actual voice or data communications between the connected 
customers. Among the components that need to communicate to establish voice and 
data communication links are the mobile units, the base station system connected by 
radio to the mobile units, the mobile switching center and the various databases that 
are consulted for the establishment of mobile calls. These databases include a home 
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location register (HLR) with an authentication center (AC (IS-41) or AuC (GSM)), a 
visitor location register (VLR), and an equipment identification register (EIR). 

Signaling messages among these components are processed by many 
expensive protocol handlers. In the past, these protocol handlers were too expensive 
to permit incorporation into a single unit. Modem switching systems typically include 
expensive MSCs, such as AT&T's 5ESS® switch. These systems only make sense for 

7 deployment when there are a large group of mobile customers who will use the 

8 system. 

This invention uses advanced signal processing, a novel method of structuring 
signal processing software and an enhanced home location register/visitor location 
register to provide multi-protocol, scaleable mobile telecommunications capability. 
The software architecture is specifically designed so that generic processing is used to 
the maximum extent possible to process signals and data related to different digital 
and analog protocols including GSM, TDMA, CDMA and AMPS, and proprietary 
15 protocols. 

Figure la shows a general arrangement of a mobile telecommunications 
environment 100. At the heart of this environment 100 is an aircore platform 200 of 
the invention. The aircore platform 200 receives messages from, and transmits 
messages to a variety of fixed and mobile sources, conforming to each of the protocols 

20 employed by the sources. 

21 Base transceiver stations (BTSs) 1 10 receive messages from and transmit 
messages to the aircore platform 200 over land lines 1 13. The land lines 1 13 may be 
any telecommunications medium that is capable of high speed data transmission, such 
as fiber optic cable, T-l and E-l lines and coaxial cable, for example. 

The BTS 1 10 transmits messages to and receive messages from mobile and 
fixed sources. In Figure la, the BTSs 1 10 are shown in wireless communication with 
mobile phones 1 12, a mobile phone in a car 1 16 (a roaming mobile phone), a 
microcell 1 15, and a wireless local loop 150. The wireless local loop 150 may include 
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1 several connections. The wireless local loop 150 is described in more detail below. A 

2 telephone 1 18 may operate in conjunction with a private branch exchange (PBX). 

3 The BTSs 110 may operate in conjunction with the fixed and mobile sources, 

4 according to one of several wireless protocols as set forth above. 

5 The aircore platform 200 communicates with a public switched telephone 

6 network (PSTN) 120 via a wired path 121 and with a wireless network 130 via a 

7 signal path 131. 

8 The aircore platform 200 also communicates with a satellite 141 via a satellite 

9 receiver 140. 

10 Figure lb shows a GSM wireless environment 101. The aircore platform 200 

1 1 connects to the BTS 1 10 via a base station controller (BSC) 105. Mobile units 1 12, 

12 the roaming mobile phone 116, the wireless local loop 150 and the microcell 1 15 

13 communicate by way of wireless radio channels with the BTS 1 10. The aircore 

14 platform 200 also connects to a GSM MAP network 133 via landline 132 and to the 

15 PSTN 120 via the landline 121 . Finally, the aircore platform 200 communicates with 

16 the satellite 141 via the antenna 140. 

17 Figures lc and Id show wireless environments 102 and 103, respectively. The 

18 wireless environment 102 is used with CDMA-protocol mobile units and base 

19 stations, and the wireless environment 103 is used with TDMA-protocol wireless 

20 units and base stations. 

21 Figure 2 shows the aircore platform 200 in more detail. In Figure 2, the 

22 aircore platform 200 includes a mobile switching center (MSC) 210. The MSC 210 is 

23 configured such that the aircore platform 200 can receive and transmit multiprotocol 

24 wireless communications and wired communications with a variety of platforms. The 

25 MSC 210 may include a visitor location register (VLR). Alternately, the VLR may 

26 be separated from the MSC 210. The aircore platform 200 also includes a home 

27 location register (HLR) 212. The HLR 212 includes permanent information about 

28 customers who use the local environment serviced by the aircore platform 200. The 

29 data stored in the HLR 212 is the permanent data that is independent of the customers 
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present location, plus temporary data stored such as the address of the system (may be 
signaling system 7 (SS-7) or other system) where the mobile unit is currently 
registered and the address of service centers that have short messages for a mobile 
unit. An example of such a short message is a request to turn on a voice message 
waiting lamp indicating that a voice message has been stored for the mobile unit's use 
in a voice messaging system. These addresses are erased after the short messages 
have been delivered. The signaling system 7 (SS-7) is described in detail in A.R. 
Modarressi, etal., "Signaling System No. 7: A Tutorial," IEEE Communications 
Magazine, July 1990, pp. 19-35. 

The VLR contains the profile data for the mobile unit and the transient data for 
each mobile customer, including the mobile unit's present or most recently known 
location area, the mobile unit's on/off status, and security parameters. 

An authentication center 213 is used to ensure that only properly authorized 
mobile and wired sources communicate through the aircore platform 200. The 
authentication center 213 provides authentication encryption parameters to ensure that 
a mobile customer cannot falsely assume the identity of another mobile customer and 
provides data for encryption of the voice data, and control signals transmitted via the 
air between the mobile unit and the servicing base station system. Encryption is 
desirable for the transmission of messages between the mobile unit and the radio 
transceiver at a base station serving that mobile unit because it is possible to listen in, 
or tap, the radio channels carrying voice communications. 

An equipment identity register (EIR) 21 1 includes a database of the mobile 
equipment using the aircore platform 200, including specific protocols and equipment 
preferences. The EIR 211 retains the ranges of certified equipment identifications and 
the ranges of, or the individual equipment identifications that are under observation or 
barred from service. The equipment identification information is received from a 
mobile unit at the MSC 210. The EIR 21 1 is used to verify that the equipment 
number of the mobile unit is certified for use in the public network and is not on the 
observation or service barred list. 
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1 The MSC 210 is connected to other wireless network components and to the 

2 PSTN for accessing land-based customer stations and to the integrated services digital 

3 network (ISDN) for communicating according to ISDN protocols. A base station 

4 system (BSS) 104 may include the BSC 105 and one or more BTSs 1 10 for 

5 communicating with mobile units. The BSS 104 and the mobile units communicate 

6 via radio connections. The BSS 104 is also connected via trunks to carry the voice, 

7 data, and control messages between the mobile units and the MSC 210. The BSC 105 

8 and the BTS 110 may be in different physical locations (for example, the BSC 105 

9 may be co-located with the MSC 210 in which case a trunk is required to interconnect 

10 the two). This is done since the communications between the BTS 1 10 and the BSC 

11 105 can typically be compressed to optimize the BTS connectivity requirements. 

12 Figures 3-7 show different mobility architectures that can be used with the 

13 aircore platform 200. In Figure 3, the aircore platform 200 is shown communicating 

14 with the BTS 1 10. The BTS 1 10 may service the wireless local loop 150. The aircore 

15 platform 200 may also connect with the PSTN 120. 

16 Figure 4 shows the aircore platform 200 used in conjunction with fixed 

17 wireless local loop customers. In Figure 4, the fixed wireless local loops 151 include 

18 a number of fixed customers in each of the local loops 151. The local loops 15 1 

19 provide telephony services to fixed wireless customers in their respective loops. The 

20 services are provided via a fixed terminal (not shown) that is attached to a location 

2 1 and typically extends via a standard two-wire or similar connection to an analog 

22 telephone within the location. Call processing and feature management are handled 

23 by the aircore platform 200 as for a normal wireless customer. The only difference for 

24 the aircore platform 200 is that the area of operation for the fixed terminal does not 

25 change. Even though the terminal is using a wireless interface for communications, 

26 the terminal's location remains fixed. The aircore platform 200 processes the calls to 

27 and from the customer in the same manner as with mobile wireless calls because the 

28 air interface determines the protocol and the feature set that is to be used to 

29 communicate with the customer's fixed terminal. The protocol can be any of the 
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1 wireless protocols (CDMA, TDMA, AMPS, GSM). To limit the area of 

2 communications for a particular fixed terminal, the aircore platform 200 can be 

3 configured to only allow service to a particular location area for a particular fixed 

4 terminal. 

5 The aircore platform 200 provides a full range of mobile services to a wireless 

6 local loop, or location area. In Figure 5, the aircore platform 200 is shown providing 

7 mobile services to a wireless local loop 152 and a wireless local loop 153. In this type 

8 of mobility situation, customers may move with their wireless terminals in a given 

9 wireless local loop or location area. Movement outside of the location area is not 

10 supported for these types of terminals. A typical implementation of this type of 

11 mobility is provided in a village or town scenario where the coverage is disjointed 

12 from other parts of the telecommunications system. 

13 Figure 6 shows a system level mobility scenario that permits mobility for the 

14 customer across all location areas under the control of the local aircore platform 200. 

15 In Figure 6, the location area 154 and the location area 155 are both serviced by the 

16 aircore platform 200. Moreover, customers in the location area 154 may freely move 

17 through the location area 154 and the location area 155 and maintain wireless 

18 communications with the aircore platform 200. This type of scenario can be found in 

19 multiple towns or villages where a common aircore platform 200 is shared and the 

20 coverage is contiguous or there is a considerable amount of allowable travel between 

21 the locations covered by the system. 

22 Figure 7 shows a full scale mobility scenario. In Figure 7, the aircore platform 

23 200 communicates with a public land mobile network (PLMN) 158 and with local 

24 wireless loops 156 and 157. The local wireless loops 156 and 157 also communicate 

25 with the PLMN 158. This configuration provides for incoming and outgoing roaming 

26 traffic to and from the local aircore platform 200 to other switching centers, which 

27 may also be aircore platforms 200. 

28 Figure 8 is a block diagram of a wireless network architecture according to the 

29 invention. In Figure 8, the aircore platform 200 includes a MSC/VLR 2 10', a home 
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1 location register 224, an authentication center 226, and an equipment identification 

2 register 225. The aircore platform 200 communicates with the base station system 

3 (BSS) 104' using one or more protocols including GSM, CDMA, TDMA, and AMPS. 

4 The aircore platform 200 also communicates with the PSTN 220 and other elements 

5 of the wireless network. An alternate mobile telecommunications switch is also 

6 shown in Figure 8. A MSC/VLR 210' ' is coupled to the PSTN 220 and the BSS 104". 

7 However, other modular components used in the mobile telecommunications 

8 environment are located remotely from the MSC/VLR 210". A system management 

9 controller 230, a home location register 221, an equipment identification register 222 

10 and an authentication center 223 may be physically separated from the MSC/VLR 

1 1 210". However, the functions of these modular components remain the same, 

12 whether they are located with or remote from the MSC/VLR 210' and 210", 

13 respectively. 

14 Figure 9 shows the functions and connections of the aircore platform 200. In 

15 Figure 9, the visitor location register, the home location register, the equipment 

16 identification register and the authentication center are shown co-located with the 

17 MSC 210. The aircore platform 200 connects to the PSTN 120 via a T-l/E-1 line. 

18 The aircore platform 200 is adapted to receive land-line originated telephone 

19 messages. The aircore platform 200 can then send a connect message to an 

20 appropriate base station system. The aircore platform 200 also allows intersystem 

21 connection to an IS-41 wireless network 170 via a SS-7 link and a GSM wireless 

22 network 160 via a SS-7 link. Optionally, these links may be based on other 

23 communication carriage mechanisms such as IP, X.25, frame relay, or asynchronous 

24 transfer mode (ATM). 

25 The aircore platform 200 provides for intrasystem, or base station, wireless 

26 communication using GSM protocols via a GSM BSC 240 and BTS 241. The aircore 

27 platform 200 provides wireless communications using CDMA and TDMA via a IS- 

28 634 link, an IS-95A BSC 244, a BTS 243 and a IS- 136 BSC 242 and BTS 249. The 

29 aircore platform 200 communicates with an AMPS BTS 246 using the ISDN PRI+ or 
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the IS-634 protocol. The aircore platform 200 provides communications with a 
private branch exchange (PBX) 248 via T-l/E-1 lines. The aircore platform 200 also 
provides for connection to a billing system 260 using TCP/IP protocols, for example, 
and for voice mail and messaging functions via voicemail module 250. 

TABLE A 



6 


TYPE 


PROTOCOL 


APPLICATION 


7 


Base Station 


GSM "A" (Series 4 and 8) 


GSM Network 


8 




IS-651 & J-STD 


US GSM based PCS 


9 




IS-634 as- 136) 


DAMPS Network 


10 




IS-634 (IS-95A) 


CDMA Network 


11 




IS-634 (AMPS) 


Analog Network 


12 




ISDN PRI+(AMPS) 


Analog Network 


13 


Intcrsystem 


GMS 09.02 


GSM Network 


14 




IS-652 


US GSM based PCS 


15 




ANSI-41 


DAMPS, DCMA, AMPS Network 


16 


PSTN 


T-l 


T-l Interface (various protocols) to the PSTN 


17 




E-l 


E-l Interface (various protocols to the PSTN 


18 
19 


Tandem 


T-l 


T-l Interface tandem call traffic between local PBX 
and the PSTN 


20 
21 




E-l 


E-l Interface tandem call traffic between local PBX 
and the PSTN 


22 


Voice Mail 


T-l 


T-l Interface to voice mail system 


23 




E-l 


E-l Interface to voice mail system 


24 
25 


Billing 
Center 


TCP/IP 


Interface for the transfer of Call Detail Records 


26 
27 
oo 


NMC/OMC 


TCP/IP 


Interface for the exchange of Network Management 
related information 



Table A shows a list of interfaces from the aircore platform 200 and the 
functionality each of the interfaces adds. A Network Management Center/Operation 
and Maintenance Center (NMC/OMC) 262 communicates with the aircore platform 
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200 using TCP/IP protocols, for example. The billing system 260 and the NMC/OMC 
262 may also communicate with the aircore platform 200 using CCITT X.25 
protocols. 

Figure 10 is a block diagram of the aircore software architecture 300. In 
Figure 10, the architecture 300 is shown including a system control module SCM 
layer 310, a call processing control module handling the real time application layer 
400, and a device handler layer 500. The SCM layer 310 maintains responsibility for 
non-real time related applications, such as report management and configuration. The 
SCM layer 310 generates and collects various types of report data, system 
configuration information and system maintenance procedures. The SCM layer 310 
may be logically and physically separated from the rest of the aircore software 
architecture 300. 

The call processing control module of the real time application layer 400 
handles the application layer tasks that are real-time related. At the real time 
application layer 400 of software, direct knowledge of specific protocols is not 
required. Instead, this layer handles functions from a generic standpoint. For 
example, a call processing state machine processes mobile originated call set up in the 
same manner regardless of the type of interface used to connect to the base station 
equipment. The event set and state machine commonality allow lower layers of 
software to change without effecting the call processing control module of the real 
time application layer 400. 

The device handler layer 500 is the lowest layer of software in the aircore 
software architecture 300. The device handler layer 500 contains the specific software 
applications to receive and transmit protocol specific messages. 

The SCM layer 3 10 includes a control panel (CTL) 3 12, which is the father 
process of all the other processes in the system. The CTL 312 is responsible for 
startup and auditing of the overall aircore software architecture 300. Once started, the 
CTL 312 is only involved in limited auditing functions. 



-15- 



WO 00/46938 



PCT/US00/02797 



1 A call record management (SCR) 3 14 tracks the call report data generated in 

2 the system. These records can be used for billing tracking, system tendencies, or 

3 prepaid type of access. Call records are archived and the files rotated periodically. 

4 For example, the files may be rotated hourly. Real-time output is accessible via 

5 standard output options such as a printer or a screen output. Archived output is 

6 accessible on screen, or may be accessed over a standard TCP/IP network or dial up. 

7 An operational measurements manager (OMM) 3 1 6 is responsible for tracking 

8 system counters. A count is defined as the occurrence of a particular situation. Each 

9 time the situation occurs, the counter is incremented. Operational measurements are 

10 archived and the files rotated periodically. For example, the files may be rotated 

1 1 hourly. Each time a new file is created, each of the counters is reset to zero. This type 

12 of data is captured to allow an operator to track system performance and tendencies 

13 over time. Operational measurements are archived into files rotated periodically. 

14 Real-time output is accessible using standard output options such as a printer or a 

15 screen output. Archived output is accessible on-screen or can be accessed over a 

1 6 standard TCP/IP network or dial up. 
A real-time log report manager (RTL) 318 tracks system level reports. System 

level reports are generated to notify an operator of certain tasks or situations occurring 

19 on the aircore platform 200. For example, at the top of the hour, the system level 

20 audit log reports may be output. Log reports range from reporting normal system 

21 maintenance events to system status changes. Log reports are archived into files 

22 rotated periodically. Real-time output is accessible using standard output options such 

23 as a printer or a screen output. Archived output is accessible on screen or can be 

24 accessed over a standard TCP/IP network or dial up. 

25 An auto removal process (AUTO) 322 is responsible for automatic removal of 

26 outdated archived report files. Automatic removal may occur on a periodic basis, 

27 such as monthly. 

28 A network management database aciministration (NMS) 324 allows access to 

29 databases that provide configuration information for routing, rating and language for 



17 
18 
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1 mobile devices. A system configuration (S YSCFG) 326 allows access to the 

2 configuration of system telephony hardware resources. A system maintenance 

3 (SYSMTC) 328 allows access to operator-initiated maintenance procedures. 

4 A visitor location register interface VLI 332 provides the operator access to a 

5 visitor location register. A home location register interface (HLI) 334 provides an 

6 operator interface to the home location register and authentication center information. 

7 An equipment identity register interface (EH) 336 provides an operator interface to the 

8 equipment identity register. The VLI 332, HLI 334 and EH 336 may be implemented 

9 as a graphical user interface(s) (GUI) or as batch type operations. These interfaces 

10 will be described in more detail later. 

1 1 The call processing control module (CPCM) of the real time application layer 

12 400 includes a recovery and startup (REC) 402, which is the father process of the 

13 software subsystems in the real time application layer 400 and at the device handler 

14 layer 500. The REC 402 manages the maintenance states for the trunk and signaling 

15 facilities in the real time application layer 400. The REC 402 interfaces with each of 

16 the device handlers in the device handler layer 500 for maintenance and status as well 

17 as with graphical user interface-based applications in the SCM layer 3 10 to process 

18 operator initiated maintenance requests. The REC 402 also initiates an audit of all 

19 real time application layer 400 subsystems. The audit may run every two minutes, for 

20 example, and provides assurance that all subsystems are running properly. 

21 A fault analysis unit (FAU) 404 is responsible for the collection of all log 

22 reports and operational measurement related data created within the CPCM 400. The 

23 FAU 404 to real-time layer interface is a singular path for this information to pass. 

24 All CPCM 400 subsystems have access to pass events to the FAU 404 for this 

25 purpose. 

26 The timer manager (TIM) 406 provides timing facilities to call processing 

27 control module subsystems in the aircore platform 200. The TIM 406 is used for 

28 application level timers that operate on a one second or greater granularity. Timers 

29 are stored in a list and are tracked until they are released or until they expire. Timers 
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requiring finer granularity or those that are specific to a particular subsystem's 
requirements are controlled locally either in the subsystem or on board in the 
hardware. The timers associated with the aircore platform 200 will be described later 
in more detail. 

A resource manager (RCM) 408 is used to manage base station resources 
connected to the aircore platform 200. The RCM 408 has the capability to configure, 
download, and track the state of individual cell site components as well as the base 
station as a whole. 

A CPCM call record management (CCR) 412 module provides for local 
collection of call detail record (CDR) information for calls in progress. When calls 
are completed, the CDR information is transferred from the CCR 412 to the SCR 314 
in the SCM 310, where the call record data is processed and stored. 

A call processing manager (CPM) 414 provides the processing required for all 
communication channel establishment, tear down, feature processing and hand off 
control. The state machines in place in the CPM 414 are based on a half-call model. 
Each party in a session moves through a defined set of states based on received and 
sent events, and timers used. Each side of a call steps through its own state. The two 
sides of the call progress together. For a basic call setup, the state of one side of the 
call is never more than one step ahead or behind the state of the other side. In the 
CPM 414, each call placed requires the creation of a session object. This object is 
created based on an index number created from the board span and channel used by 
the originator of the call. The session adds and removes call objects as dictated by the 
progress of the call. The reference number for the session is always based on the 
originator's board span and channel. However, the session may also be indexed via 
the index number of the board, span and channel of any of the involved parties. 

A hand off processor (HOP) 416 is responsible for the preprocessing required 
for hand off or hand over (GSM). Based on the technology and the involvement of 
intersystem border cells, the level of involvement of the HOP 416 varies from one air 
interface protocol to the next. However, like other modules performing specific 
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1 functions, the unique aspects of the protocol are handled internally in the HOP 416. 

2 The interface to the CPM 414 for hand off processing is made generic. Preprocessing 

3 in relation to handoff processing refers to the collection of data and the decision 

4 process used to determine the appropriate base station to target for the hand off. This 

5 entire process has been formed into a generic procedure within the aircore software 

6 architecture 300. 

7 A tone and announcement manager (TAM) 418 is responsible for management 

8 of the digital signal processor resources in the system used for playing tones and 

9 announcements. The TAM 418 interacts directly with the CPM 414 to provide the 

10 necessary digital signal processor allocations. The digital signal processors are 

1 1 controlled by components of the device handler 500. Direct communication to the 

12 device handler from the CPM 414 is avoided so that the CPM 414 does not have to 

13 maintain direct knowledge of the current digital signal processor configuration and 

14 allocations. 

15 A visitor location register (VLR) 422 is responsible for establishing and 

16 maintaining a VLR database for the aircore platform 200. As shown in Figure 10, the 

17 VLR 422 is co-located with the aircore platform 200. However, the VLR 422 could 

18 be located remotely from the aircore platform 200. The VLR 422 is a collection of 

19 customer profiles for users currently active on the system. The VLR 422 is a dynamic 

20 database created and maintained while the aircore platform 200 is running. The VLR 

21 422 communicates with threads inside an Advanced Intelligent Message Handler 

22 (AIM) 430, which will be described later, for real-time application messaging. Any 

23 communications to or from the VLR 422 from the CPCM 400 are received via the 

24 AIM 430. Communications with the VLJ 332 are limited to those necessary to allow 

25 for the display of individual customer profile information, listing the current profiles 

26 in the VLR 422 and allowing an operator the ability to update customer profiles from 

27 the VLR database. 

28 A home location register/authentication center (HLR) 424 is responsible for 

29 establishing and maintaining the HLR database for the aircore platform 200. As 
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1 shown in Figure 10, the HLR 424 is co-located with the aircore platform 200. 

2 However, the HLR 424 could also be located remotely from the aircore platform 200. 

3 In addition, the functions of the HLR 424 could be carried out in separate HLR and 

4 AC modules. The HLR 424 includes a collection of permanent customer profiles for 

5 users homed on the system. The HLR 424 is a static database that tracks the current 

6 location of a customer in addition to the individual profile parameters and status of 

7 customer-related features. The HLR 424 communicates with the AIM 430 for real- 

8 time application messaging. Any communications to or from the HLR 424 in the 

9 CPCM 400 are received via the AIM 430. Communications with the HLI 334 are 

10 limited to those necessary to allow for the manipulation of individual customer 

1 1 profiles, listing the current customer profiles in the HLR 424, and allowing an 

12 operator to update the customer profiles. 

13 The HLR 424 also contains the functionality to perform the advanced security 

14 calculations used in digital air interface protocols. These calculations are based on a 

15 piece of secret data combined with a random number to yield a result that only has 

16 meaning to the authentication center and the mobile unit. This functionality is 

17 included in the HLR database and is integrated as part of the customer profile. The 

1 8 actual comparison of data is done in the AIM 430 or in the HLR 424 itself, depending 

19 on the protocol. Since the authentication center is integrated in the HLR 424, 

20 communications with the authentication center all funnel through the HLR 424. The 

21 authentication process will be explained in more detail later. 

22 ^ equipment identity register (EIR) 426 is responsible foi establishing and 

23 maintaining an EIR database for the aircore platform 200. The EIR database is a 

24 collection of the serial number information for mobile telephone handsets and other 

25 equipment in the system. The EIR 426 normally maintains at least three lists: 

26 White - range listing of valid international mobile equipment identities 

27 (International Mobile Equipment Identity (IMEI)) (serial numbers). 

28 Gra Y - list of individual serial numbers of questionable phones. Usage is 

29 operator dependent. 
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1 Black - list of individual serial numbers of equipment prohibited from using 

2 the system. 

3 The EIR 426 is used with GSM-type systems. However, application to other 

4 system protocols may also be accomplished. The EIR 426 communicates with the 

5 AIM 430 for real-time application messaging. Any communications to or in the EIR 

6 426 from the CPCM 400 are received via the AIM 430. Communications between the 

7 EIR 426 and the EH 336 are limited to those necessary to allow for the manipulation 

8 of list information. This includes allowing an operator to add, modify and delete from 

9 the information the EIR database. 

10 The device handler 500 includes a portion of the AIM 430. The device 

1 1 handler 500 includes a device handler for digital CAS interface (DHD) 501, a device 

12 handler for voice input and output devices (DHA) 502, a device handler for ISDN 

13 interfaces (DHI) 503, a device handler for conference (DHC) 504, and a device 

14 handler for timers (DHT) 505. The AIM 430 also includes a device handler for SS-7 

15 (DH-7)510. 

16 Figure 1 1 is a logical diagram of the advanced intelligent message handler 

17 (AIM) 430. The AIM 430 provides for advanced protocol processing, message 

18 routing and system interfaces for the wireless network. The AIM 430 is built around 

19 the steps required to establish call processing, mobility, and servicing in a wireless 

20 environment. The basic approach of the AIM 430 is to use a multi-thread system to 

21 isolate protocols and functions required for the mobility environment. Each different 

22 protocol family supported by the aircore platform 200 is handled by a thread 

23 specifically constructed for the message sent and state machine for that protocol. 

24 Communications to various software entities such as the VLR, HLR, and EIR 

25 funnel through the AIM 430 subsystem. This approach is taken to remove the 

26 knowledge of the low layer message destination from each of those entities. This 

27 approach also allows for the isolation of protocol specifics to the AIM 430 layer of 

28 software. Finally, this approach allows for the seamless separation of these functions 

29 to physically separate entities without effecting the application software. The 
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1 following is an example of the benefit of this approach: When the CPM 414 needs to 

2 request the current location of a subscriber from the HLR 424, the message is sent to 

3 the AIM 430 subsystem without the direct knowledge of the HLR location or the 

4 protocol used to communicate with the HLR 424. The AIM 430 handles the routing 

5 (either internal or external) and the selection and construction of the appropriate 

6 message based on the protocol. 

7 In Figure 1 1 , a main AIM thread 438 is shown along with subordinate threads 

8 43 1-436. In addition, a common memory 439 is used to share data related to a 

9 transaction or connection between the subordinate threads 43 1 -436 and the device 

10 handler for SS-7 (DH-7) 510. Since each of the procedures followed for call 

1 1 establishment, location updating, etc., involve multiple threads and actions, the 

12 common memory 439 optimizes the performance of the AIM 430 by reducing the 

13 copying of data between threads while at the same time allowing data sharing across 

14 all of the threads by simply passing a pointer. 

1 5 The A-interf ace message handler ( AMH) 43 1 provides message decoding and 

16 encoding for interface processing between an external base station and the aircore 

17 platform 200 event structures and state machines. 

1 8 Figure 12 is a block diagram of the logical architecture of the A-interface 

19 message handler AMH 43 1 . Communications received from a base station interface 

20 are first interpreted by the AMH 43 1 . The encoding and decoding specification for a 

21 particular protocol are contained in dynamic linked libraries 441 and 442 that are 

22 linked to the AMH 43 1 . Each variant of the A-interface has its own unique set of 

23 builder/decoder dynamic linked libraries. Each type of A-interface utilizes its own 

24 instance of the AMH 43 1. Also shown in Figure 12 are timers 443; through 443 n . 

25 The timers 443;-443 n , which control operations of state machine call processing for a 

26 given connection, will be described in more detail later. 

27 Figure 13 is a logical block diagram of the ISUP message handler (SMH) 436 

28 logical architecture. The SMH 436 provides appropriate message conversion between 

29 the application programming interface and the internal aircore subsystem event 
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structures. As shown in Figure 13, the SMH 436 is logically linked to the board levels 
at boards 444,-444 n . 

Figure 14 is a logical block diagram of the intersystem message handler (IMH) 
432 architecture. The IMH 432 encodes and decodes protocol messages related to a 
mobile unit from an external communications system. These messages are called 
Mobile Application Part. The encoding and decoding specifications for a particular 
protocol are contained in the dynamic linked libraries 445 and 446 that are linked to 
the IMH 432. Each variant of the MAP interface has its own unique set of 
builder/decoder dynamic linked libraries. Each type of MAP interface utilizes its own 
instance of the IMH thread 432. Also shown linked to the IMH thread are timers 
447,-447 n . The function of the timers 447 will be described in more detail later. 

An authentication and registration processing (ARS) thread 434 (see Figure 
11) provides appropriate calculations, comparisons and invocations of the required 
authentication for a given base station interface. A paging processing (PAG) thread 
435 (see Figure 11) provides the processing necessary for paging in the AirCore 
system. Paging is the mechanism for locating and starting the process of notifying a 
mobile unit of an incoming call or message. 

Figure 15 is a logical block diagram of the device handler for voice I/O 
devices (DHA) 502. The DHA 502 provides control of voice I/O resources in the 
aircore platform 200 that are used for playing tones and announcements. The DHA 
502 is a single process that spawns individual threads for each digital signal processor 
that is accessible. As shown in Figure 15, the DHA 502 spawns digital signal 
processor threads 522, through 522 n . The aircore platform 200 uses the first five 
digital signal processors in the system to play standard tones. These tones are 
accessible to all ports on the system. This approach satisfies the requirements of 
playing ring-back or busy tones to all ports simultaneously. After the first five digital 
signal processors, the remaining digital signal processors are allocated to a pool that 
may be used in real-time call processing to play tones or announcements for call 
progressing. The five digital signal processors are used for the standard tones of ring 
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1 back, busy, fast busy, dial tone and confirmation beep. To play announcements for 

2 call progressing, the DHA 502 works with the tone and announcement manager 

3 (TAM) 418 (not shown, see Figure 10), which receives its commands from the CPM 

4 414. 

5 Figure 16 shows the device handler for digital channel associated signaling 

6 (CAS) interface (DHD) 501 in more detail. Channel associated signaling is a method 

7 of signaling in telecommunications where a portion of each channel between two 

8 entities is allocated for the carriage of the signaling and supervision in formations. 

9 The DHD 501 is a multi -thread, multi-process subsystem that provides for CAS 

10 processing. 

1 1 Each channel in the DHD 501 is allocated a thread for processing the low layer 

12 protocol state machine. As shown in Figure 16, spans 51 1,-51 l n are associated with 

13 processing threads 512 r 512 24/32 and 513 r 513 24/32 , The top layer process in the DHD 

14 501 architecture is responsible for the interworking between the thread output in the 

15 real time application layer 400. 

16 Figure 17 shows the device handler for ISDN interfaces (DHI) 503. The DHI 

17 503 is a multi-threaded, single process subsystem that provides processing for 

18 common channel signaling interfaces. The DHI 503 is used internally in the aircore 

19 platform 200 to handle facilities (T-l or E-l) that use common channel signaling 

20 methods. Common channel signaling provides a single signaling channel for the 

21 control of signaling and supervision information for many channels of resources (e.g., 

22 a single channel is used to pass the appropriate signaling for all of the associated 

23 traffic channels). Typically the signaling channel is based on an industry signaling 

24 method such as SS-7, LAPD, or TCP/BP. In the DHI 503, a top layer process is 

25 responsible for communications to the internal aircore platform 200 subsystems. 

26 Linked to the DHI 503 are board level threads 520 r 520 n . The board level threads 

27 520 r 520 n are used to handle individual boards in the aircore platform 200. 

28 Figure 18 is a logical block diagram of a device handler for SS-7 (DH-7) 510. 

29 The DH-7 510 exists for the purpose of handling the board level API for the SS-7 
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1 links in the system. The main tasks of the DH-7 510 are the basic assignment of 

2 threads to the SS-7 links and assuring proper message routing for inbound messages to 

3 the interned aircore subsystems and threads. Each SS-7 link established in the system 

4 has its own link level thread that exists as a subordinate thread to the main DH-7 510 

5 thread. 

6 Figure 19 is a logical block diagram showing interlayer communications 

7 among the SCM layer 3 10, the real time application layer 400 and the device handler 

8 layer 500. In Figure 19, a two-way communications path 350 between the CTL 3 12 

9 and the REC 402 is used to start the real time application layer 400 and report the 

10 appropriate status information. One-way path 351 is used to transfer CDRs from the 

1 1 real time application layer 400 to the SCM layer 310. One-way path 352 between the 

12 FAU 404 and the RTL 3 18 is used to transfer report and operational measurement 

13 pegs from the real time application layer 400 to the SCM layer 310. One-way path 

14 353 between the SYSMTC 328 and the REC 402 is used to pass maintenance related 

15 commands to the real time application layer 400 from the SCM layer 310. Two-way 

16 path 354 from the VTJ 332 to the VLR 422 is used to exchange information between 

17 the VLR 422 and the VLR graphical user interface 332. Two-way path 355 between 

18 the HLI 334 and the HLR 424 is used to exchange information between the HLR 424 

19 and the HLR graphical user interface 334. Two-way path 356 between the EH 336 

20 and the EIR 426 is used to exchange information between the EIR 426 and the EIR 

21 graphical user interface 336. 

22 Path 450 between the REC 402 and subsystem at the device handler layer 500 

23 is defined for startup, status and maintenance communications used to interact with 

24 the telephony board level hardware. The REC 402 communicates directly with all 

25 device handler level subsystems with the exception of the DH-7 510, which is handled 

26 via communications with the AIM 430. Two-way path 45 1 between the CPM 414 and 

27 the device handler layer 500 is established for the exchange of messages for call 

28 processing related activities in the aircore platform 200. The CPM 410 communicates 

29 directly with all device handler 500 level subsystems with the exception of the DHA 
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1 502 and the DH-7 5 1 0. Communications path 452 between the TAM 4 1 8 and the 

2 DHA 502 provides for the allocation and deallocation of voice I/O resources for tones 
and announcements. Much like trunk groups that abstract the physical location of 
trunks, this level of communication abstracts the physical location of the digital signal 
processors used for playing the tones and announcements. Communications path 453 
between the AMH 43 1 , SMH 436, IMH 432 and the DH-7 5 1 0 provides for 

7 communications between the SS-7 links and the builder/decoder threads in the AIM 

8 430. 

9 Figure 20 is a logical representation of the HLR 424. The HLR 424 contains 
permanent data that is independent of the customer's present location, plus temporary 
data such as the current location of the system where the mobile unit is registered and 
the addresses of service centers that have stored short messages for mobile stations. 
An example of such a message is a request to turn on a voice message waiting lamp 

14 indicating that a voice message has been stored for the mobile station user in a voice 

15 messaging system. These addresses are erased after the short messages have been 

16 delivered. 

17 As shown in Figure 20, the HLR 424 includes customer profiles 460, for each 

18 mobile customer. The customer profile 460, includes a customer data module 461. 

19 The customer data module 461 includes a customer group identification, which is a 

20 four digit number specifying the routing translations index for the customer. The 

21 number must be previously configured in a routing translations data base via a routing 

22 administration window. The customer data module 461 also includes the International 

23 Mobile Customer Identity (TMSI), the International Mobile Equipment Identity (IMED 

24 or Electronic Serial Number (ESN), which is the serial number of the handset 

25 hardware, and the Kj, or A-key which is the key used for authentication calculations. 
The customer data module 461 also includes the name of the customer, the language 
for customer announcements, a three to five digit carrier ID identifier for long distance 
carrier code associated with the customer, a check box for calling card features and a 

29 prepaid feature. A call offering module 462 includes an indication of current features 
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1 such as call forwarding unconditional (CFU), call forward busy (CFB), call 

2 forwarding no reply (CFNRy), and call forwarding not reachable (CFNRc), and call 

3 forwarding default (CFD). 

4 A VLR/MSC data module 463 indicates the VLR in and the MSC associated 

5 with the current area of operation of the customer. A personal identification number 

6 (PIN) data module 464 indicates if the customer uses a PIN when accessing the 

7 system for calling card or long distance calls and the four digit PIN number associated 

8 with the customer. A protocols module 465 is used for multi-mode customers to 

9 determine the capabilities of the customers' units. The protocols may include, but are 

10 not limited to, TDMA, CDMA, GSM and AMPS. A call restriction module 466 

1 1 stores features for restricting the calling capabilities of the customer to and from the 

12 network. The call restriction features include baring of all outgoing calls, suspended 

13 service (no calls allowed), baring of all outgoing international calls, baring of all 

14 incoming calls, baring of all outgoing international calls except those to the home 

15 PLMN country and baring incoming calls to a customer when they are roaming to 

1 6 another system. 

17 A call features module 467 indicates the set of features allocated to a 

18 customer. The call features include call hold, multi-party calling, 3-way calling, 

19 roaming, call waiung and access to sending and receiving short messages. Aline 

20 identification module 468 identifies features that provide/restrict calling and called 

21 number information to various parties in a call. The line identification features 

22 include calling line ID presentation, calling number presentation, connected line ID 

23 presentation, calling line ID restriction, calling number restriction, and connected ID 

24 restriction. 

25 A message center data module 469 provides for storage of short messages 

26 pending delivery to a customer's mobile unit. 

27 The HLR 424 may also include an authentication center. The authentication 

28 center provides authentication and encryption parameters to insure that a mobile 

29 customer cannot falsely assume the identity of another mobile customer. The 
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authentication center also provides data for encrypting the voice or data and control 
signals transmitted via the air between the mobile station and the serving base station 
subsystem. A GSM reference model prescribes digital communications over the radio 
channels. Since it is possible to surreptitiously listen to these channels, encryption 
becomes desirable for the link between the mobile station and the radio receiver at a 
base station serving that mobile station. Any public or proprietary encryption 
algorithm known in the art can be used with the aircore platform 200. 

The calculations for the authentication center use the secret key information 
- associated with the subscriber and the protocol specific calculations. The HLR 424 
pre-processes these authentication calculations and stores them as part of the 
subscriber profile. As required, this information is shared with the servicing 
MSC/VLR to authenticate the mobile unit as it accesses the system. 

The VLR 422 contains current data for each active mobile customer, including 
that customer's mobile station present or most recently known location area, the 
mobile unit's on/off status, and security parameters. The VLR 422 is logically 
constructed in the same manner as the HLR 424. 

The HLR and VLR databases both simultaneously accommodate customer 
profiles from any interface protocol. There are two significant classifications of 
profile types, based on the intersystem protocol used to transmit and receive profile 
information over the wireless network. Both GSM and IS-41 based networks share 
common information in the customer profile structures, but each profile type also 
requires fields and information that are unique to that particular protocol type. The 
HLR and VLR databases provide for this by an internal structure that uses a common 

top level header for me common data and then protocol specific attachments. This 
internal structure is shown in Figure 21. A GSM side 417 and an IS-41 side 419 are 
used with the VLR and HLR databases. A common data header 427 is used for both 
GSM and IS-41 profile information. A GSM specific data area 428 is used for GSM 
specific data. An IS-41 specific data area 429 is used for IS-41 specific data. The 
common data header 427 allows the two sides of the database to use common search 
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1 routines while the specific data areas allows for the storage of data that pertains to a 

2 specific protocol alone. 

3 A description of the timers used by the MSC 210 will now be provided. A call 

4 proceeds from initiation to connection through a series of steps. The time associated 

5 with this call set up and connection is usually short. Nonetheless, one or more voice 

6 channels may be reserved at the start of the call set up. If the call will not connect, 

7 some mechanism is desirable to release these resources as quickly as possible so that 

8 they may be used by other customers. Furthermore, during the time that the mobile 

9 unit is held waitingfor an incoming call, the mobile unit cannot call out or receive 

10 other incoming calls. To free up resources and to release the mobile unit, the TMR 

1 1 437, in conjunction with the TIM 406 (see Figure 10) includes a number of timers that 

12 may be established at various points in the call set up and connect process. The timers 

13 are generally set based on a message from the AMH 43 1 or similar interface. 

14 A timer may be set when a device handler such as the device handler 510 

15 requests a BSC 105 to assign a channel. In this case, the AMH 43 1 sends a message 

16 to the TMR 437 to set the timer. If an assignment is not completed within the time 

17 limit of the timer, the call connection process ends. If the assignment is completed 

1 8 before expiration of the timer, the AMH 43 1 sends a message to the TMR 437 to 

1 9 , release the timer. 

20 A timer may be associated with a connect message sent to the BSC 105 by a 

21 device handler. If a connect acknowledgment message is received by the device 

22 handler, the AMH 431 will send a timer release message, allowing the call connection 

23 to complete. Similarly, a timer may be set to time out a make call command, a paging 

24 message for a mobile terminated call, a disconnect message (GSM) or release message 

25 LS-634) for PSTN and mobile originated calls, and a clear command to release a 

26 channel during a call disconnect sequence. Other timers may be used to ensure 

27 resources are returned for assignment to other calls. 

28 Managing the location of a customer ensures the proper connection of the 

29 customer's mobile unit for both mobile initiated calls and mobile terminated calls. In 
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1 Figure 22, the authentication and registration (ARS) 434 thread is shown in 

2 communication with the common memory 439. The common memory 439 includes 

3 the data relevant to the mobile unit and the state machine relevant to the protocol and 

4 the transaction being performed. The ARS 434 maintains communications with the 

5 AMH 43 1 and the IMH 432 to track ongoing transactions, to compare SRES, to send 

6 TMSI to the mobile unit and to provide ciphering information to the AMH 43 1 . The 

7 IMH 432 provides connections to the VLR 422 and HLR 424 for obtaining customer 

8 profile information. 

9 The call processing module (CPM) 414 processes calls according to one of 

10 several state machines. A state machine exists for each half of every call processed 

1 1 through the aircore platform 200. A separate state machine exists for mobile 

12 originated call processing, PSTN originated call processing and mobile terminated call 

1 3 processing, for example. Figures 23-25 are examples of state machines used in 

14 processing calls at the aircore platform 200. Figure 23 is a state machine 600 for 

15 mobile originated call processing. In Figure 23, eight states are possible: idle (SI), 

16 wait for UUI (S2), wait for page response (S3), wait for alert (S4), wait for connect 

17 (S5), voice (S6), wait for handoff confirm (S7), tone and announce (S8), and wait for 

1 8 call cleared (S9). The state machine 600 shows the allowed transitions between 

19 states. Starting in idle S 1, the state machine 600 can transition to state wait for UUI 

20 S2 or wait for call cleared S9. The state machine 600 transitions to wait for UUI S2 

21 based on reception of the mobile customer s profile when a CALL RECEIVED 

22 message is received. The state machine 600 transitions from idle S 1 to wait for call 

23 cleared S9 based on the mobile customer profile indicating a particular call restriction 

24 or if the call fails before routing. With the authentication previously set up with the 

25 A-interface protocol, this transition may not be possible. 

26 111 ti* wait for UUI state S2, the state machine 600 can transition to the wait 

27 for alert state S4. This transition is based on receiving the ROUTE.CALL message. 

28 The aircore platform 200 proceeds with making the call out to the called party if the 

29 call type is direct dial (DD) in the routing translations or when a call delivery to a 
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1 mobile unit or another system is required. The CPM 414 then sends a MAKE.CALL 

2 message. Next, the state machine 600 can transition from the wait for UUI state S2 to 

3 the wait for page response S3 based on receiving a ROUTE.CALL message. A 

4 PAGE_MOBILE message is sent to the PAG 435. The transition to this state is based 

5 on a call type of MOB in the routing translations and finding that the called mobile 

6 unit is operating in the aircore system. The state machine 600 transitions from the 

7 wait for UUI state S2 to the tone and announce state S8 if the dialed number received 

8 from the originating mobile unit fails to translate properly or if there is a restriction on 

9 the called mobile unit. The originating mobile unit is then connected to a tone. This 

10 transition could also occur by the CPM 414 receiving a PAGEJRJ2SPONSE message 

1 1 with a time out indication. Finally, the wait for UUI state S2 can transition to the wait 

12 for call cleared state S9 based on receiving a disconnect from the mobile unit. When 

13 the message CALL_DIS CONNECTED is received at the CPM 414, a CLEAR_CAUL 

14 message is sent. 

15 The state machine 600 transitions from the wait for page response S3 to the 

16 wait for alert state S4 based on receiving a PAGEJRESPONSE message. A 

17 MAKE_CALL message is then sent and the CPM 414 proceeds with an ISDN state 

18 machine 600. The wait for page response state S3 transitions to the tone and 

19 announce state S8 along transition path T8 based on receiving a time out for a page 

20 response. The CPM 414 then provides a time out announcement or tone to the calling 

21 party. The state machine 600 transitions from the wait for page response state S3 to 

22 the wait for call cleared state S9 along transition path T9 based on receiving a 

23 disconnect from the originating mobile unit. A CALL_DISCONNECTED message is 

24 received at the CPM 414 and a CLEAR__CALL message is sent. The PAG thread 435 

25 will time out and clear the page request data for the call. 

26 The state machine 600 transitions from the wait for alert state S4 to the wait 

27 for connect state S5 along transition path T10 based on receiving an alerting 

28 indication from the called party. The alerting indication is passed to the mobile 

29 customer's side of the call. The CPM 414 receives the CALL„ALERTING message 
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1 from the called party and sends an AUERT.CALL to the originating mobile unit. The 

2 transition from the wait for alert state S4 to the voice state S6 occurs along transition 

3 path Tl 1 based on receiving a connect indication from the called party. The protocol 

4 allows a CONNECT message to be received without receiving alerting. The CPM 

5 414 receives a CALL_CONNECTED message from the called party and sends a 

6 CQNNECT_CALL message to the originating mobile unit. The transition from the 

7 wait for alert state S4 to the tone and announce state S8 is along transition path T12. 

8 This transition occurs for two possible reasons. First, the transition may be based on a 

9 time out waiting for the alerting indication. The called party is cleared from the call 

10 and the mobile customer is connected to an announcement or tone. The CPM 414 

1 1 sends a CLEAR_CALL message to the called party. Second, the transition may be 

12 based on receiving a disconnect from the called party with "user busy." The 

13 originating mobile unit is sent an announcement and the called party is released from 

14 the call. The CPM 4 14 receives a CALL_DIS CONNECTED message from the called 

15 party and sends a CLEAR.CALL message to the called party. Finally, the transition 

1 6 from the wait for alert state S4 to the wait for call cleared state S9 occurs along 

17 transition path T13 if the originating mobile customer disconnects from the call before 

18 the CPM 414 receives the alerting indication from the called party. Clearing both 

19 parties is initiated. The CALL.DIS CONNECTED message is received from the 

20 originating mobile unit. The CPM 4 14 sends a CLEAR.CALL message to both 

21 parties. 

22 ' rbe state machine 600 may transition from the wait for connect state S5 to the 

23 voice state S6 along transition path T14 based on receiving connect indication from 

24 the called party. The connect indication is passed to the mobile customer. The CPM 

25 414 received a CALL.CONNECTED message from the called party and sends a 

26 CONNECT_CALL message to the originating mobile unit. Transition from the wait 

27 for connect state S5 to the tone and announce state S8 occurs when a time out occurs 

28 waiting for the connect. The called party is cleared from the call and the mobile 

29 customer is connected to a tone or announcement. The CPM 414 sends a 
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1 CLEAR_CALL message to the called party. Transition from the wait for connect 

2 state S5 to the wait for call cleared state S9 occurs along transition path T16 if the 

3 originating mobile subscriber disconnects from the call before the CPM 414 receives 

4 the connect indication from the called party. Clearing both parties is initiated. The 

5 CPM 414 receives a CALL_DISCONNECT message from the originating mobile unit 

6 . and sends a CLEAR_CALL message to both parties. 

7 The state machine 600 transitions from the voice state S6 to the wait for called 

8 clear state S9 along transition path T17 based on receiving a disconnect indication 

9 from either party. Call clearing is initiated for both parties on the call. A 

10 CALL_DIS CONNECTED message is received from one of the parties. The CPM 

11 414 sends a CLEAR_CAJLL message to both parties. Transition from the voice state 

12 S6 to the wait for hand off confirm state S7 occurs along transition path T18 based on 

13 receiving a hand off request from the HOP 416 subsystem and having a B-channel to 

14 allocate to the target BTS for the hand off. The CPM 414 receives a HAND_OFF 

15 request from the HOP 416 and sends a MAKE_CALL message with a hand off 

16 indicating to establish the target channel. Finally, the voice state S6 transitions back 

17 to the voice state S6 along transition path T19 based on receiving a hand off request 

18 and not having a B-channel available to the BTS. 

19 The state machine 600 transitions from the wait for hand off confirm state S7 

20 to the voice state S6 along transition path T20 based on three possible events. First, 

21 the CPM 414 receives a hand off confirmation from the serving BTS. This indicates 

22 the mobile unit has confirmed the hand off and is in transition to the target BTS. The 

23 voice connection is switched to the target BTS at this point. The CPM 414 receives a 

24 HAND_OFF_CONFIRM message and sends a CLEAR_CALL to the old serving 

25 channel. The voice path in connected to silence until the CALL.CONNECTED 

26 message is received on the target channel. Second, the CPM 414 receives a hand off 

27 confirmation with a negative indication (failed). This indicates that the mobile unit is 

28 not going to the target channel. The CPM 414 starts a disconnect sequence to release 

29 the target channel. The CPM 414 then sends a CLEAR_CALL message to the target 
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channel. Third, the CPM 414 receives a failure on the channel setup with the target 
BTS. The transition to the voice state S6 occurs and the CPM 414 initiates or 
continues with the disconnect sequence with the target BTS channel. The CPM 414 
sends a CLEAR.CALL message to the target channel. Transition from the wait for 
confirm state S7 to the wait for call cleared state S9 occurs along transition path T21 
based on receiving a disconnect from either party while a target BTS channel is being 
established for the hand off. The CPM 414 initiates clearing all resources and 
transition. The CPM 414 receives a CALL_DISCONNECTED message and sends a 
CLEAR CALL message to the parties. 

The state machine 600 transitions from the tone and announce state S8 to the 
wait for call clear state S9 along transition path T22 based on the originating mobile 
unit disconnect indication being received from the CPM 414. This can occur as a 
result of a time out after the tone or an announcement is played and a disconnect is not 
received. In this case, the CPM 414 initiates the disconnect with the mobile customer. 
The CPM 414 initiates the disconnect with the mobile customer. The CPM 414 either 
receives a CALL.DISCONNECTED message and sends a CLEAR.CALL message 
or the CPM 414 receives a time out and sends a CLEAR_CALL message. 

The state machine 600 transitions from the wait for call cleared state S9 to the 
idle state S 1 along transition path T23 based on both parties confirming they are 
cleared from the call. In cases where there is no other party involved in the call, the 
confirmation of the clearing of the party is implied by the fact that the cell never 
existed. This transition takes place when the call is completely cleared. The CPM 
414 receives a CALL_CLEARED message from the originating mobile unit. 

Figure 24 is a state machine 601 for PSTN originated call processing. In the 
state machine 601 , the wait for UUI state S2 and the wait for handoff confirm state S7 
are not allowed states. The state machine 601 transitions from the idle state S 1 to the 
wait for page response state S3 along transition path T24 based on determining the 
need to page the mobile customer. The CPM 414 sends a PAGE_MOBILE message 
to the PAG thread 435. Transition from the idle state S 1 to the wait for alert state S4 
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1 occurs along transition path T25 based on determining that the mobile customer is 

2 located on another system and the aircore platform 200 has received a routing number 

3 to call the current serving switch. The CPM 414 sends a MAKE_CALL message 

4 using the TLDN (MSRN GSM). The transition from the idle state 51 to the wait for 

5 alert state 54 can also occur under a forwarding condition of the original destination 

6 number. Transition from the idle state SI to the tone and announce state S8 occurs 

7 along transition path T26 if the called number received from the originating PSTN 

8 party fails to translate properly or if there is a restriction on the called mobile unit. In 
: 9 this case the originating PSTN party is connected to a tone or announcement. This 

10 transition could also occur by the CPM 414 receiving a PAGE_RESPONSE message 

1 1 with a time out indication. 

12 The state machine 601 transitions from the wait for page response state S3 to 

13 the wait for alert state S4 along transition path T27 based on receiving a 

14 PAGE_RESPONSE message. The CPM 414 sends a MAKE_CALL message and 

15 proceeds with the ISDN state machine. Transition from the page response state S3 to 

16 the tone and announce state S8 occurs along transition path T28 based on receiving a 

17 time out for a page response (i.e., PAGE_RESPONSE message received by the CPM 

18 414 with a time out indication). The CPM 414 provides a time out announcement or 

19 tone to the calling party. Transition from the wait for page response state S3 to the 

20 wait for call cleared state S9 occurs along transition path T29 based on receiving a 

21 disconnect from the originating PSTN party. The CPM 414 receives a 

22 CALL_DIS CONNECTED message and sends a CLEAR_CALL message. The PAG 

23 thread 435 will time out and clear the page request data for the call. 

24 The state machine 601 transitions from the wait for alert state S4 to the wait 

25 for connect state S5 along transition path T30 based on receiving an alerting 

26 indication from the called party. The alerting indication is passed to the PSTN side of 

27 the call. The CPM 4 14 received a CALL_ALERT1NG message from the called party 

28 and sends an ALERT_CALL message to the originating PSTN party. Transition from 

29 the wait for alert state S4 to the voice state S6 occurs along transition path T3 1 based 
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1 on receiving a connect indication from the called party. The protocol allows reception 

2 of the connection without receiving alerting. The CPM 414 receives a 

3 CALL_CONNECTED message from the called party and sends a CONNECT„CALL 

4 to the originating PSTN party. Transition from the wait for alert state S4 to the tone 

5 and announce state S8 occurs along transition path T32 for two possible reasons. 

6 First, transition may be based on a time out waiting for the alerting indication. The 

7 called party is cleared from the call and the PSTN party is connected to an 

8 announcement or tone. The CPM 414 sends a CLEAR_CALL message to the called 

9 party. Second, transition may be based on receiving a disconnect from the called party 

10 with "user busy." The originating PSTN party is sent an announcement and the called 

1 1 party is released from the call. The CPM 414 receives a CAIXJDISCONNECTED 

12 message from the called party and sends a CLEAR CALL message to the called party. 

13 Transition from the wait for alert state S4 to the wait for call cleared state S9 occurs 

14 transition path T33 if the originating PSTN party disconnects from the call before the 

15 CPM 414 receives the alerting indication from the called party. Clearing of both 

16 parties is initiated. The CPM 414 receives a CALL_DISCONNECTED message from 

17 the originating PSTN party and sends a CLEAR_CALL message to both parties. 

18 The state machine 601 transitions from the wait for connect state S5 to the 

19 voice state S6 along transition path T34 based on receiving connect indication from 

20 the called party. The connect indication is passed to the PSTN party. The CPM 414 

21 receives the call connected message from the called party and sends the 

22 CONNECT_CALL message to the originating PSTN party. Transition from the wait 

23 for connect state S5 to the tone and announce state S8 occurs along transition path 

24 T35 when a time out occurs waiting for the connect. The called party is cleared from 

25 the call and the PSTN party is connected to a tone or announcement. The CPM 414 

26 sends a CLEAR_CALL message to the called party. Finally, transition from the wait 

27 for connect state S5 to the wait for call cleared state S9 occurs along transition path 

28 T36 if the originating PSTN party disconnects from the call before the CPM 414 

29 receives the connect indication from the called party. Clearing both parties is 



-36- 



WO 00/46938 



PCT/US00/02797 



initiated. The CPM 414 receives a CALL.DIS CONNECTED message from the 
originating PSTN party and sends the CLEAR_CALL message to both parties. 

The state machine 601 transitions from the voice state S6 to the wait for call 
cleared state S9 along transition path T37 based on receiving a disconnect indication 
from either party. Call clearing is initiated for both parties. The CPM 414 receives 
the CALL_DIS CONNECTED message from one of the parties. The CPM 414 then 
sends the CLEAR_CALL message to both parties. 

The state machines 601 transitions from the tone and announce state S8 to the 
wait for call cleared state S9 along transition path T38 based on the originating mobile 
unit disconnect indication being received from the CPM 414. This can also occur as a 
result of a time out after the tone or announcement is played and a disconnect is not 
received. In this case, the CPM 414 initiates the disconnect with the mobile customer. 
The CPM 414 either receives a CALLJDIS CONNECTED message and sends a 
CUEAR_CALL message or the CPM 414 receives a time out and sends the 
CLEAR_CALL message. 

The state machine 601 transitions from the wait for call cleared state S9 to the 
idle state S 1 along transition path T39 based on both parties confirming they are 
cleared from the call. In cases where there is no other party involved in the call the 
confirmation of the clearing of the party is implied by the fact that it never existed. 
Transition takes place when the call is completely cleared. The CPM 414 receives the 
CALL_CLEARED message from the originating mobile unit. 

Figure 25 shows a state machine 602 for a mobile terminated call processing. 
As shown in Figure 25, the states wait for UUI S2, wait for page response S3 and tone 
and announce S8 are not used in a mobile terminated call processing scenario. The 
state machine 602 transitions from the idle state S 1 to the wait for alert state S4 along 
transition path T40 based on reception of a valid PAGE.RESPONSE message. The 
CPM 414 sends a MAKE.CALL message to the terminating mobile unit. The idle 
state S 1 returns to the idle state SI along transition path T41 based on a page time out, 
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1 or failure in routing. The calling party is sent to an announcement or the call is 

2 forwarded based on the customer's feature profile. 

3 State machine 602 transitions from the wait for alert state S4 to the wait for 

4 connect state S5 along transition path T42 based on receiving an alerting indication 

5 from the terminating mobile customer. The alerting indication is passed to the calling 

6 party's side of the call. The CPM 414 receives a CALL ALERTING message and 

7 sends a ALERT.CALL message to the calling party. Transition from the wait for alert 

8 state S4 to the voice state S6 occurs along transition path T43 based on receiving a 

9 connect indication from the called mobile unit. The protocol allows receipt of a 

10 receive connect message without receiving alerting. The CPM 414 receives a CALL_ 

1 1 CONNECTED message from the called party and sends a CONNECTJTALL 

12 message to the calling party. Transition from the wait for alert state S4 to the wait for 

13 call cleared state S9 occurs along transition path T44 if the calling party disconnects 

14 from the call before the CPM 414 receives the alerting indication from the mobile 

15 customer. Clearing both parties is initiated. The CPM 414 receives a CALL 

16 DISCONNECTED message from the calling party and sends a CLEARCALL 

17 message to both parties. In addition, in time out cases where the calling party is sent 

18 to an announcement, the called mobile unit will receive a CLEAR_CALL message 

19 from the CPM 414 and make the transition. 

20 The st ate machine 602 transitions from the wait for connect state S5 to the 

21 voice state S6 along transition path T45 based on receiving a connect indication from 

22 the called mobile customer. The connect indication is passed to the calling party. The 

23 CPM 4 14 receives a C A1X CONNECTED message and sends a CONNECTCALL 

24 message to the calling party. Transition from the wait for connect state S5 to the wait 

25 for call clear state S9 occurs along transition path T46 that the calling party 

26 disconnects from the call before the CPM 414 receives the connect indication from 

27 the mobile customer. Clearing both parties is initiated. The CPM 414 receives a 

28 CALL DISCONNECTED message from the calling party. The CPM 414 then sends a 

29 CLEARCALL message to both parties. In addition, in time out cases where the 
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1 calling party is sent to an announcement, the called mobile unit will receive a 

2 CLEAR_CAUL message from the CPM 414 and make the transition. 

3 The state machine 602 transitions from the voice state S6 to the wait for call 

4 cleared state S9 along transition path T47 based on receiving a disconnect indication 

5 from either party. Call clearing is initiated for both parties in the call. The CPM 414 

6 receives a CALL_DISCONNECTED message from one of the parties and sends a 

7 CLEAR.CALL message to both parties. Transition from the voice state S6 to the wait 

8 for hand off confirm state S7 occurs along transition path T48 based on receiving a 

9 hand off request from the HOP subsystem 416 and having a B-channel to allocate to 

10 the target BTS for the hand off. The CPM 414 receives a hand off request message 

1 1 from the HOP 416 and sends a MAKECALL message with a hand off indication to 

12 establish the target channel. Transition from the voice state S6 back to the voice state 

13 S6 occurs along transition path T49 based on receiving a hand off request and not 

14 having a B-channel available to the BTS. 

15 The state machine 602 transitions from the wait for hand off confirm state S7 

16 to the voice state S6 along transition path T50 in one of three situations. First, the 

17 CPM 414 receives a hand off confirmation from the serving BTS. This indicates the 

1 8 mobile unit has confirmed the hand off and is transitioning to the target BTS. Voice 

19 connection is switched to the target BTS at this point. The CPM 414 receives the 

20 HANDOFF.CONFIRM message and sends the CLEAR.CALL message to the old 

21 serving channel. The voice path is connected to silence until the CALL. 

22 CONNECTED message is received on the target channel. Second, the CPM 414 

23 receives a hand off confirmation with a negative indication (failed). This indicates 

24 that the mobile unit is not going to the target channel. A disconnect sequence to 

25 release the target channel is started and the CPM 414 sends a CLEAR.CALL message 

26 to the target channel. Third, the CPM 414 receives a failure of the channel set up with 

27 the target BTS. Transition to the voice state S6 in initiation or continuation of the 

28 disconnect sequence with the target BTS channel begins. The CPM 414 sends a 

29 CLEAR.CALL message to the target channel. Transition from the hand off confirm 
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7 
8 



1 state S7 to the wait for call cleared state S9 occurs along transition path T5 1 based on 

2 receiving a disconnect from either party while a target BTS channel is being 

3 established for the hand off. The CPM 414 initiates clearing all resources and 

4 transition. The CPM 414 receives a CALL DISCONNECTED message and sends a 

5 CLEAR CALL message to all parties. 

6 The state machine 602 transitions from the wait for call cleared state S9 to the 
idle state S 1 along transition path T52 based on both parties confirming they are 
cleared from the call. In cases where there is no other party involved in the call, the 

9 confirmation of the clearing of this party is implied by the fact that a call never 

10 existed. This transition takes place when the call is completely cleared. The CPM 

414 receives a CALL CLEARED message from the originating mobile unit. 

The aircore platform 200 uses a common facility state machine for tracking the 
states and conditions of external connections or trunks. Two portions of the state are 
tracked. Each facility has a near end and a far end state. The near end state represents 
the internal aircore state for the facility. The far end state represents the state of the 
facility as reported by the connected system. This state machine tracking applies to all 
aircore interfaces including traffic channels and signaling channels. Like call 

18 processing, these maintenance procedures are generic in the aircore platform 200 

19 regardless of the interface. 
Figure 26 is a aircore near end facility maintenance state machine 604. The 

state machine 604 includes the states not configured (S10), blocked (SI 1), unblocked 
pending (S 12), unblocked (S 13), call processing (S14), blocked pending (S15), and 

23 maintenance (SI 6). 

24 Figure 26 also shows the transitions between the states of the state machine 
604. The state machine 604 transitions from the state not configured S10 to the 
blocked state SI 1 along transition path T60 when a facility is added to the 

27 configuration and is enabled. 

28 1116 state machine 604 transitions from the blocked state S 1 1 to the unblocked 
pending state S12 over transition path T61 when either operator initiated or automatic 
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1 recovery occurs which requests that the destination device handler bring the requested 

2 facility to an unblocked (in service) state. Transition from the blocked state SI 1 to the 

3 maintenance state S 16 occurs along transition T62 when the facility is taken to a 

4 maintenance state to perform a maintenance or test operation. This transition is based 

5 on an operator action. Transition from the blocked state S 1 1 to the not configured 

6 state S 10 occurs along transition path T63 when the facility is disabled and/or 

7 removed from the system configuration. 

8 The state machine 604 transitions from the unblocked pending state S 12 to the 

9 unblocked state S13 over transition path T64 when a maintenance action is confirmed 

10 by the device handler. The facility is now in service. Transition from the unblocked 

1 1 pending state S 12 to the blocked pending state S 15 occurs over transition path T65 

12 when a maintenance action is denied by the device handler or aborted by an operator 

13 action. 

14 The state machine 604 transitions from the unblocked state S 13 to the call 

15 processing state S14 along transition path T66 when the facility is allocated and will 

16 be used for call processing. Transition from the unblocked state S 13 to the blocked 

17 pending state S 15 occurs along transition path T67 when either operator initiated or 

18 automatic maintenance action from the device handler. Transition also occurs based 

19 on other internal action requests that the destination device handler bring the 

20 requested facility to a blocked (off-line) state. 

21 The state machine 604 transitions from the call processing state S 14 to the 

22 unblocked state S 13 over transition path T66 when the facility is released from being 

23 used in call processing. Transition from the call processing state S 14 to the blocked 

24 pending state S 15 occurs over transition path T69 when a maintenance action is either 

25 operator initiated or automatic from the device handler or other internal action 

26 requests that the device destination handler bring the requested facility to a blocked 

27 (off-line) state. 

28 The state machine 604 transitions from the blocked pending state S 15 to the 

29 blocked state S 1 1 over transition path T70 when a maintenance action to take facility 
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1 off-line is confirmed by the device handler. In a case where the device handler does 

2 not respond, the state may be reached by default of no response. 

3 The state machine 604 transitions from the maintenance state S16 to the 

4 blocked state S 1 1 over transition path T7 1 when the maintenance action on the facility 

5 is completed. Operator action is required to transition the state back to the blocked 

6 state Sll. 

7 In addition to monitoring the near end state of the system facilities, the aircore 

8 platform 200 also maintains the far end state of facilities where applicable. The far 

9 end state represents the status of a facility at the connected system side. The far end 

10 state and near end state are used together to determine the overall operational state. 

1 1 Figure 27 shows the aircore far end facility maintenance state machine 605. In 

12 Figure 27, the states are not configured (S 17), blocked (S 18), unblocked (S 19), and 

13 unknown (S20). 

14 The state machine 605 transitions from the not configured state S17 to the 

15 blocked state S 18 along transition path T80 when a facility is added to the 

16 configuration and enabled. 

17 The state machine 605 transitions from the blocked state S 18 to the unblocked 

1 8 state S 19 over transition path T8 1 when an unblocking request is received from the far 

19 end. Confirmation is then sent back with an unblocking acknowledgment message. 

20 Transition from the blocked state S 1 8 to the unknown state S20 occurs over transition 

21 path T82 when a discrepancy has been detected between the state reported by the far 

22 end and the stored far end state for the facility in aircore platform 200. The blocked 

23 state S 18 transitions to the not configured state S 17 over transition path T83 when the 

24 facility is disabled and/or removed from the system configuration. 

25 The state machine 605 transitions from the unblocked state S 19 to the blocked 

26 state S 18 over transition path T84 when a blocking request message is received from 

27 the far end. Confirmation is sent back with the blocking acknowledgment message. 

28 Transition from the unblocked state S 19 to the unknown state S20 occurs over 
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1 transition path T85 when a discrepancy has been detected between the state reported 

2 by the far end and the stored far end state for the facility in the aircore platform 200. 

3 The state machine 605 transitions from the unknown state S20 to the blocked 

4 state S 18 over transition path T86 when the far end reports the state of the facility is 

5 blocked. Transition from the unknown state S20 to the unblocked state S19 occurs 

6 over transition path T87 when the far end reports the state of the facility is unblocked. 

7 Hand off processing occurs when an active mobile unit transitions from a 

8 wireless region supported by one base station to a wireless region supported by a 

9 second base station. Hand off processing may also occur as a mobile unit transitions 

10 from one cell site within a wireless region to another sell site. 

1 1 Figure 28 shows an aircore wireless environment 106 in which the aircore 

12 platform 200 functions as a mobile switching center (MSC). There are many different 

13 protocol scenarios that are possible for hand off processing in the aircore environment 

14 106, including ISDN PRI+ with an AMPS base station, DHD-based (AMPS) base 

15 station, IS-634 AMPS, IS-634 TDMA, IS-634 CDMA, GSM, IS-41 Revision B, IS-41 

16 Revision C and GSM mobile application part (MAP). In addition, the processing 

17 design of the aircore platform 200 retains the flexibility to easily adapt to other hand 

18 off protocols. Finally, the aircore platform 200 may receive hand off requests from 

19 multi-protocol mobile units. 

20 In Figure 28, base station controllers (BSCs) 105,, and 105 2 and base 

21 transceiver stations (BTSs), are shown connected to the aircore platform 200 via 

22 signal lines 485 and 495, respectively. The BSC 105, has an associated wireless 

23 region 480 that includes BTSs 481, 482 and 483. The BSC 105 2 has an associated 

24 wireless region 490 with BTSs 491, 492 and 493. The mobile unit 1 12 is active in the 

25 wireless region 480 at point A and communicates with a land-line phone 1 14 via 

26 PSTN 120, the aircore platform 200, the BSC 105, and the BTS 481. 

27 In the above description, the BTS receives a call from a mobile unit. The 

28 mobile unit may be a mobile telephone or a computer with a wireless modem, for 
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1 example. In addition, the BSC/BTS may be replaced in some scenarios with a BSS or 

2 any other base station configuration. 

3 During the course of a call, the mobile unit 1 12 transitions from point A in 

4 wireless region 480 to point B in wireless region 490. As a result of this transition, 

5 the BTS 105, detects that the signal level of the cell has dropped below the minimum 

6 to continue the call on the current channel. The BSC 105, notifies the aircore 

7 platform 200, which begins hand off processing to establish a new cell site using the 

8 BSC 105 2 . When the new cell site is established, the aircore platform 200 tears down 

9 the previous link, thereby freeing up resources for other wireless customers. 

10 In the scenario described above, the BSC 105j and 105 2 are both associated 

1 1 with the aircore platform 200 and certain hand off processing functions such as 

12 strength measurements are performed by the aircore platform 200. In a scenario 

13 involving a base transceiver station coupled to another mobile switching center, the 

14 base transceiver stations may perform these hand off processing functions. 

15 As with other processing functions, the software architecture 300 of the aircore 

16 platform 200 is designed to use, as much as possible, generic processing for mobile 

17 unit hand offs. Thus, communications from the mobile units operating according to 

1 8 different protocols, e.g., GSM, TDMA, CDMA and AMPS are handled in a generic 

19 fashion, except where specific differences are required. The message flows associated 

20 with these protocols will be described later. 

21 Referring to Figure 10, once a base station detects that the signal level has 

22 either dropped below the minimum, or exceeded the maximum, to continue the call on 

23 the current channel, hand off processing begins. Measurements are taken of bordering 

24 systems to determine the best candidate system, or target base station. The HOP 416 

25 is involved in this for analog protocols and some inter-system hand offs Otherwise, 

26 the step may be handled directly between the base station and the mobile unit. For 

27 digital protocols, the base station sends the target information to the HOP 416 for 

28 transmission to the CPM 414. For ISDN PRI + and DHD based analog protocols, the 

29 HOP 416 determines the appropriate target for the hand off. Next, the CPM 414 is 
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1 notified via the HOP 416 of the required hand off and begins establishing a voice 

2 circuit to the target system. Once confirmed, the CPM 414 sends the hand off 

3 command to the current serving base station. This information is passed to the mobile 

4 unit. The mobile unit confirms the reception of the target information and switches to 

5 the new frequence and voice path. Upon arrival at the new frequency, the new serving 

6 base station passes the confirmation to the CPM 414. The CPM 414 switches the 

7 voice path during this process to the new channel and tears down the voice path to the 

8 old serving system. 

9 As noted above, the HOP 416 preprocess is limited. After the hand off is in 

10 progress, the HOP 416 is no longer involved. Call processing uses the information 

1 1 provided by the HOP 416 to establish appropriate resources to complete the hand off. 

12 Call processing is responsible for the control of the remaining portion of the hand off. 

13 For ISDN PRI+ protocol hand offs, a message is sent to the aircore platform 

14 200 from a base station to indicate that a mobile unit requires a hand off. The 

15 message specifies a protocol discriminator, a call reference (whose value is assigned 

16 in a SETUP message), a message type and a user identification. The aircore platform 

17 200 in turn sends a hand off message request to the base station to request the base 

18 station measure a specific frequency. Finally, the base station sends a message to the 

19 aircore platform 200 to report the measured strength of the signal recorded on the base 

20 station. 

21 ISDN PRI+ processing requires that the HOP 416 accept a hand off request 

22 from the DHI 503. Appropriate hand off related information, including call reference 

23 and RF channel, for example, is stored in the air core platform 200. The call reference 

24 is a number that is retrieved from the device handler thread data that is initially stored 

25 when call setup takes place. The RF channel is also retrieved from the device handler 

26 thread data. The air core platform 200 then sends measurement requests to 

27 appropriate boarder cells, sets a measurement request timer, and processes responses 

28 from the base station. 
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1 For DHD based protocol hand offs, the HOP 416 accepts a hand off request 

2 from one of the device handlers in the aircore platform 200. The appropriate hand off 

3 related information, including the call reference and RF channel, for example, are 

4 stored. The aircore platform 200 allocates a voice channel and sends measurement 

5 requests (SCANs) to the appropriate border cells, sets a measurement timer, and 

6 processes responses received from the base stations. For base stations not chosen for 

7 hand off, the aircore platform 200 initiates a channel release. If a suitable target cell is 

8 determined, the HOP 4 1 6 send the information to the CPM 4 14 for hand off. 

9 For DHD based protocol hand off processing, a voice channel is assigned to 

10 each base station when the measurement process takes place. For example, if three 

1 1 base stations border the current wireless system and a measurement is to be taken, a 

1 2 voice channel is explicitly reserved in each base station. When the target base station 

1 3 is chosen, the voice channels in the other base stations must be released. To 

14 accomplish this release, the device handlers will allocate and release the appropriate 

15 channels for the measurements in accordance with commands sent by the HOP 416. 

16 If an allocation fails or there are no channels available in a base station, the device 

17 handlers send allocation failure events to the HOP 416, and the HOP 416 removes the 

1 8 base station from the candidate list for the current hand off. 

19 IS-634 analog hand off processing requires the HOP 416 to send a 

20 measurement request to the AIM 430. The measurement request is then sent to 

21 appropriate border cells. The measurement requests are sent back to the requesting 

22 base station, and the information is forwarded to the HOP 4 1 6, for determination of 

23 the target cell. 

24 ^ strength measurement message is transferred to cells that are listed in a 

25 Cell Identifier List parameter that is sent in the message. The HOP 416 stores the 

26 reference number against the requesting base station so the return messages find the 

27 correct base station. The reference number is timed in accordance with a base station 

28 timer for measurement collection. Responses received after timer expiration are 

29 discarded. 
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IS-634 TDMA hand off processing requires that the HOP 416 determine, 
based on information received from the base station in a hand off required message, 
the appropriate candidate cell. The HOP 416 then sends the appropriate information 
to the CPM 414. If the HOP 416 does not find a suitable target cell, the hand off is 
aborted. 

IS-634 CDMA hand off processing requires the that HOP 416 determine an 
appropriate target cell, based on information received by the HOP 416 from the base 
station. The HOP 416 aborts the hand off if a suitable target cell is not determined. 

GSM hand off processing requires that the HOP 416 use information received 
from the base station in the hand off required message to determine appropriate target 
cells. Once again, the HOP 416 aborts the hand off if a suitable target cell is not 
located. 

For hand off processing from a multiple protocol base station, the message 
flows to the HOP 416 indicate the appropriate protocol of the mobile unit. For 
intersystem hand offs, messages related to the intersystem hand off preprocessing are 
sent from the HOP 416 to the IMH 432 and from the IMH 432. The border cell for 
measurement may be reached in the same manner as sending a message to multiple 
cell sites, except that the messages are intersystem. Therefore, the messages are sent 
to the IMH 432, or are received from the IMH 432 instead of the AIM 430 base 
station threads, DHI 503 or DHD 50 1 . 

Each cell supporting hand off in the aircore system 106 must have an 
associated list of border cells that are contacted in the event of a hand off attempt. 
These cells may have an identity that ties the cells to a link. These cells also have a 
protocol that the HOP 416 and the CPM 414 can use for determining message 
destination, supported protocols, and associated trunk groups, all of which may be 
used for new voice circuit allocations. 

Because the aircore platform 200 is capable of processing a number of 
different protocol messages, some mechanism must be provided to determine the 
correct protocol. For messages received from a single-protocol BSS, the aircore 
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platform 200 determines the correct protocol by reference to the protocol established 
for that particular BSS. The BSS is then associated with a signaling link mechanism 
that connects the BSS to the MSC 210. The link may be a SS-7 base, TCP/IP, LAPD, 
CAS and ATM, for example. The MSC 210 associates the type of protocol supplied 
by the BSS to any incoming messages received from the BSS. The actual protocol for 
the base station is determined when the link to the BTS or BSS is brought into service. 
One example is when the DH-7 510 spawns a thread connecting the BSS to the MSC 
210. 

To ensure signaling messages used with the aircore platform 200 perform the 
same generic function across protocols, tables of messages may be used for different 
aircore platform functions. The table that follows shows some of the messages used 
for call processing in the aircore platform 200, and the accompanying messages 
according to specific protocols. 



Internal AireCore Call 
Processing Event 


GSM 
(Euro and 
US) 


IS-634 
CDMA 


IS-634 
TDMA 


IS-634 
AMPS 


CPMJPAG_PAGE_MOBILE 


Page Request 


Page Request 


Page Request 


Page Request 


PAG_CPM_PAGE_RESPONSE 


Page Response 


Page Response 


Page Response 


Page Response 


MAKE_CALL 


Setup 


Setup 


Setup 


Setup 


CALL_RECEIVED 


Setup 


Setup 


Setup 


Setup 


ROUTE_CALL 


Assignment 
Complete 


Assignment 
Complete 


Assignment 
Complete 


Assignment 
Complete 


ALERT_C ALL 


Alerting 


Alerting 


Alerting 


Alerting 


CALL.ALERTENG 


Alerting 


Alerting 


Alerting 


Alerting 


CONNECT.CALL 


Connect 


Connect 


Connect 


Connect 


CALL.CONNECTED 


Connect 


Connect 


Connect 


Connect 


CLEAR_CALL 


Disconnect 


Disconnect 


Disconnect 


Disconnect 


CALL_D IS CONNECTED 


Disconnect 


Release 


Release 




CLEAR_CALL 


Release 


Release/Release 
Complete 


Release/Release 
Complete 


Release/Release 


CALL.CLEARED 


Release 
Complete 


Release 
Complete 


.Release 
Complete 


Release 
Complete 
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Calls may fall into one of several scenarios, including mobile originated (a 
mobile unit originates the call), mobile terminated (a call to a mobile unit) and PSTN 
originated, for example. Mobile originated calls may be received at the MSC and may 
be originated at another wireless system (intersystem). Mobile originated calls may 
also be received at a BTS and may then be passed to the MSC. 

The aircore platform 200 initiates a location update sequence to register a 
mobile unit with the aircore platform 200. A customer profile is retrieved from the 
VLR 422 or HLR 424 as necessary. Once a customer profile is retrieved, the 
procedures for call setup across the protocols is generic. The use of a standard 
internal set of procedures allows the call processing of the aircore platform 200 to be 
independent of the type of interface used when establishing the call. The events that 
are specific to a particular protocol are handled by individual components of the AIM 
430. A CALL.RECEIVED message announces arrival of an incoming call to the 
CPM 414. When this message is sent, the customer profile is included as well as the 
selected traffic channel. The CALL.RECEIVED message is sent based on proper 
profile retrieval, authentication and channel selection. A ROUTECALL message is 
sent to the CPM 414 as an indication that the call may be routed to the network since 
the traffic channel allocation to the originating mobile unit was successful. The 
ROUTECALL message is sent based on proper channel assignment for the call. An 
ALERTCALL event is received from the CPM 414 as an indication that the far end of 
the call is in the alerting state. When this event is received, an alert message is sent to 
the mobile unit. A CONNECT_CALL event is received as an indication that the far 
end has connected the call. This indication is passed on to the mobile station in the 
connect message. The above four events are used between the CPM 414 and all other 
subsystems for call originations in the system. 

Mobile termination also uses a set of generic events and/or messages. 
However, mobile termination is more of a challenge than mobile origination, since the 
current operating mode of a subscriber is not known prior to querying the relative 
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1 databases. Similar to the mobile origination procedure and the location updating 

2 procedure, mobile termination is generic for all base station-type interfaces regardless 

3 of the protocol. The first query is to the HLR 424 via the IMH 432. Call processing 

4 sends an event to the IMH 432 requesting the current location of the customer and 

5 how to reach the customer. This request is sent without indication of the intrasystem 

6 protocol to use. The IMH 432 utilizes the MIN/MSISDN to HLR mapping table to 

7 determine a protocol and location of the HLR in the network. 

8 For an internal HLR, the event is built and sent to the HLR 424 for processing. 

9 The protocol indicator is set based on the mapping table and a search is performed to 

10 locate the customer profile in the HLR database. If the customer profile is not found, 

1 1 the HLR 424 can optionally query the opposite side of the database in the case where 

12 the phone supports multiple modes and protocols. Once found, the VLR 422 is 

13 contacted (if not local) via standard procedures, such as ROUTEREQUEST or 

14 PROVIDE JtOAMING.NUMBER. 

15 For call tear down, the aircore platform 200 is based on the ISDN model for 

16 call release. This scenario is a three message sequence beginning with the requesting 

17 interface presenting notification of a disconnect. The notification is followed with a 

18 two event exchange with all involved subsystems for the call to command the release 

19 of the call and a return message to confirm the release. Low level processing in the 

20 aircore platform 200 ranges from changing the state of supervision bits to a two or 

21 three message exchange. 

22 Figure 29a shows the basic components of the aircore platform 200 that are 

23 involved in call processing in the above scenarios. As shown in Figure 29a, calls to 

24 the aircore platform 200 may be received at a device handler such as the DH-7 510. 

25 The device handler DH-7 510 may communicate with the IMH 432 and the AMH 

26 431. The VLR 422 and the HLR 424 and AC/AuC (not shown) may be addressed by 

27 the IMH 432 to retrieve customer-specific data and to perform other functions, 

28 including customer location, for example. The CPM 414 communicates with the ARS 

29 434, the IMH 432 and the PAG 435. 
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The components shown in Figure 29a communicate via a set of generic 
messages. These messages indicate receipt of a call, authentication, call routing and 
call connection, for example. 

To ensure proper tracking of a call and the call's processing, whenever a call 
comes into the aircore platform 200, the AMH 43 1 receives a notification from the 
DH-7 510. The AMH 43 1 accesses the decoder thread to decode the incoming 
message and to determine the appropriate action. If the message is the first message 
associated with a call, the AMH 43 1 allocates an area in the common memory 439, 
with an index to that area. For the duration of the call processing and the call, the 
designated area will be used as needed during the transaction processing. For 
example, the designated area includes the customer identification number and the base 
station identification. 

The AMH 43 1 can spawn threads unique to base station protocols such as 
GSM or RDMA, TDMA, or AMPS. The AMH 431 may also spawn different threads 
depending on the manufacturer of a mobile unit. 

The IMH 432 works in a fashion similar to that of the AMH 43 1 in that the 
IMH 432 spawns different threads, depending on the protocol required for the system 
(GSM or IS-41). When the IMH 432 deals with internal events, it shares the index 
and memory space used by the associated AMH 43 1. The IMH 432 pulls the message 
from the memory space of the common memory 439 created by the AMH 431, using 
the index created by the AMH 43 1 . 

The IMH 432 also processes events without the involvement of an AMH 431 
thread. For these situations, the index and memory area are allocated by the IMH 432 
thread. Memory and index allocation are coordinated within the AIM 430 subsystem. 

The ARS 434 communicates with the VLR 422 via the IMH 432 thread to 
retrieve the requisite information to authenticate the subscriber and determine the 
validity of the transaction. The processing of the ARS 434 thread is made generic. 

The PAG 435 thread tracks the outstanding page requests that are in process 
for the system. The PAG 435 thread receives incoming PAGE.MOBILE events from 
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1 the CPM 414 when a mobile unit is to be paged on the aircore system. The PAG 435 

2 thread determines the appropriate base station resources that should be sent the PAGE 

3 message. The PAGE.REQUEST message is then communicated to the appropriate 

4 AMH 43 1 threads for processing. In a multi-protocol environment, the decision on 

5 the base stations that receive the PAGE_REQUEST event is based on the last known 

6 technology that the mobile unit was operating on. If a mobile unit has GSM and 

7 CDMA capabilities, and the last activity for the mobile unit was on the GSM portion 

8 of the system, the PAG 435 thread will process this as a GSM based paging. If 

9 however, there is not a last known technology for the mobile unit, all technologies 

1 0 within the mobile unit's capabilities are paged. If the mobile unit referenced above did 

1 1 not have a last known technology, both the CDMA and the GSM based paging would 

1 2 take place. Once the PAGE_RES PONSE message is received, the AMH 43 1 thread 

1 3 decodes the message and sends the decoded data, via the common memory 439 to the 

14 P AG 435 thread where an association is made between the incoming 

15 PAGE_RESPONSE and the previous outgoing PAGE_REQTJEST messages. Based 

16 on the responding base station, the appropriate technology can be determined. The 

1 7 determination of the proper protocol at this point is much like the determination used 

1 8 for mobile originated actions. The responding base station determines the protocol 

19 based on its capabilities that were known when the interface to the base station was 

20 brought into service. 

21 Caa processing also uses a common reference scheme to track all events 
associated with a call. This scheme is illustrated in Figure 29b. Each call placed with 
the aircore platform 200 leads to creation of a session 490 with a session object header 
491. The session object header 491 is created based on an index number generated 
from the board, span, and channel used for the first party involved in the call. Board, 

26 span and channel is a reference created relative to the physical interface used for 

27 system access. The session 490 adds and removes call objects 492, as dictated by the 

28 progression of the call. Each session 490 has a reference number for the session that 
is based on the originator's board span and channel. However, the session may also 
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1 be indexed by an index number of the board, span and channel of any of the parties 

2 involved in the session. As shown in Figure 29b, each party object has its own data 

3 related to the customer or the interface to which it is related. 

4 The authentication process may be initiated as a result of either a service 

5 request by a mobile unit or following the successful page of a mobile unit, but is 

6 performed primarily under the control of the VLR. The authentication process may be 

7 set up to be performed every time a mobile unit originates a call or when a call 

8 terminates at a mobile unit. Authentication may also take place whenever a location is 

9 updated for the mobile unit that is in a power on or an idle state. Finally, 

10 authentication may occur when a mobile unit registers by turning power on. 

1 1 When a mobile unit originates a request for service, the mobile unit sends a 

12 message to the MSC, including the IMSI, a mobile identification number (MIN), or a 

13 temporary mobile subscriber identification (TMSI). The MSC may use the IMSI, the 

14 MIN, or the TMSI as the primary identification for the mobile unit. The IMSI is a 

15 permanent number that is assigned to every mobile unit. The MIN is a permanent 

16 number assigned to a mobile unit in the case where an IMSI is not used. (MIN is used 

17 in older AMPS based mobile units). The TMSI is assigned to a mobile unit only after 

18 an authentication, and has only local significance. If the TMSI is not recognized from 

19 the mobile unit, then a request is made to use the IMSI to continue the authentication. 

20 Upon successful authentication, a new TMSI (if used) is assigned to the mobile unit 

2 1 for future system access. 

22 The authentication center is the source of data used in authentication. The 

23 authentication center does not store data for the customers. Instead, the authentication 

24 performs calculations using random numbers that are used in conjunction with data in 

25 the HLR to generate authentication data. When a customer first subscribes for 

26 service, the customer is assigned a secret key (Kj for GSM, A-key for CDMA, 

27 TDMA). The key and a random number supplied by the authentication are used by 

28 the authentication center to generate a result. The data calculations also yield values 

29 used for encryption keys. Depending on the protocol (GSM or IS-41 based), the 
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1 authentication process can occur at different times during the establishment of 

2 communications between the mobile unit and the MSC 2 1 0. The similarities between 

3 the authentication procedures are found in the fact that they produce results that are 

4 used for both access verification and encryption. Although the security calculations 

5 the responsibility of the authentication center, the initiation of the actual 

6 collection/transmission of data and the comparison to determine the validity of the 

7 access is the responsibility of the ARS 434 thread. 

8 When authentication is requested, the MSC sends the random number of the 
mobile unit. The mobile unit retrieves the K< from its initialization memory and 
calculates a signed response (SRES) and an encryption key K,. The mobile unit then 

1 1 stores the and sends the SRES to the MSC. The ARS 434 identifies that the SRES 

12 sent by the mobile unit matches the SRES calculated by the ARS 434. If the values 

13 match, the value of stored in the mobile unit is assumed to be correct. This 
authentication process does not require that the encryption key or the initial key K, 
be transmitted over the air, thereby ensuring security for the encryption process. 

1 6 sample of the GSM authentication process is described with reference to 

17 Figure 29c. The authentication process starts with step S 10. The process then moves 

1 8 to step S 12 where a mobile unit sends a service request message to the aircore 

19 platform 200. The message includes the temporary mobile subscriber identification 

20 (TMSI). The process them moves to step S 14. In step S 14, the ARS 434 compares 

21 the TMSI sent from the mobile unit to the TMSI recorded in the VLR 422. If the ARS 

22 434 recognizes the TMSI, the process moves to step S20. Otherwise the process 

23 moves to step S 16. 

24 1x1 ste P s 16 > the ARS 434 requests the IMSI for the mobile unit from the VLR 
422. The process then proceeds to step S20. In step S20, the aircore platform 200 
sends a message to the mobile unit indicating that the mobile unit is recognized. The 

27 process then moves to step S24. 

28 111 ste P S24 « me mobile unit sends an authentication request message to the 
aircore platform 200. The process then moves to step S28. In step S28 : the aircore 
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1 platform 200 sends a random number to the mobile unit and the authentication center 

2 platform 200 sends a random number to the mobile unit and the authentication center 

3 calculates a signed response (SRES) based on the random number. The process then 

4 moves to step S30. 

5 In step S30, the mobile unit, after receiving the random number, retrieves the 

6 case Kj from its initialization memory and calculates the SRES and the encryption key 

7 IQ. The process then moves to step S34. In step S34, the mobile unit stores the 

8 encryption key K<. and sends the SRES to the aircore platform 200. The process then 

9 moves to step S38. In step S38, the ARS 434 compares the SRES calculated by the 

10 mobile unit with that calculated authentication center 200. If the two SRESs match, 

1 1 the process moves to step S44. Otherwise the process moves to step S40. In step S40, 

12 the aircore platform 200 sends a message to the mobile unit indicating that the 

13 authentication failed. 

14 In step S44, the ARS 434 completes the authentication process. The process 

15 then moves to step S48. In step S48, the ARS 434 determines if the mobile unit needs 

16 a TMSL If the mobile unit needs a TMSI, the process moves to step S50. In step S50, 

17 the ARS 434 assigns a TMSI to the mobile unit and stores the value of the TMSI in 

18 theVLR422. The process then moves to step S60. In step S 60, the authentication 

19 process ends and call processing continues. The message flows associated with a 

20 failed authentication are shown in Figure 58. 

21 The above-described authentication process is the GSM authentication 

22 procedure, which is one of several authentication procedures available to the MSC. 

23 Other authentication processes may vary according to the call processing protocol, for 

24 example. 

25 The operation of the aircore platform 200 in a multi-protocol wireless 

26 environment is explained below with reference to Figures 30-72. 

27 When the aircore platform 200 and base station controllers are first brought on 

28 line, they exchange messages to ensure that all circuits are properly aligned. Figure 30 

29 shows the reset and reset acknowledgment function when the base station controller is 
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started. In Figure 30 base station controller (BSC) 1 05 sends a reset message 620 to 
the device handler DH-7 510 to initiate the message sequence. The DH-7 510 
transfers the message to the AMH 43 1 using DH-7.AMH TRANSFER 62 1 The 
AMH 43 1 then sends an AMH REC RESET 622 to the REC 402 to initiate the reset. 
The REC 402 returns a reset acknowledge to the BSC 105 using the 
REC AMH RESET ACK 623, which is sent to the AMH 431. The AMH 431 
transfers the reset acknowledgment to the DH-7 510 using AMH DH-7 TRANSFER 
624. The DH-7 510 then sends a RESET.ACK 625 to the BSC 105. The BSC 105 
then sends a BLOCKING or CIRCUIT.GROUP BLOCK 626 to the DH-7 5 10 The 
DH-7 510 sends a DH-7.AMH TRANSFER 627 to the AMH 431, which in turn sends 
an AHM REC BLOCKING or AMH REC CIRCUIT .GROUP .BLOCKING 628 to 
the REC 402. This process then continues until all the circuits are in the appropriate 

13 state on the side of the aircore platform 200. 

14 Figure 3 1 shows the reset and reset acknowledgment message flows for a base 
controller failure. The message flows are similar to those shown in Figure 30. 

Figure 32 shows the message flows for the start up of the aircore platform 200. 
Upon startup, the REC 402 sends a REC AMH RESET 640 to the AMH 43 1 . The 
AMH 43 1 transfers the reset message to the DH-7 510, using an AMH_DH7_ 
TRANSFER 641, and starts a T16 timer 644 using AMH TMR.SET TIMER (RESET) 
643. The reset signal (RESET 642) is then sent to the BSC 105. The BSC 105 
returns a RESET ACK 645 to the aircore platform 200 and the AMH 431 releases the 
T16 timer 644 using AMH TMR.RLS.TIMER (RESET) 647. The AMH 43 1 then 
passes the reset acknowledgment to the REC 402 using AMH REC RESET ACK 648 
Finally, the BSC 105 indicates blocking or circuit group blocking by sending an 
appropriate message to the aircore platform 200. This process continues until all the 
circuits are in the appropriate state on the side of the aircore platform 200. 

Figure 33 shows the message flows for startup of the aircore platform 200 in 
28 the event of a circuit failure. 
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Figure 34 shows the message flows for startup of the aircore platform 200 in 
the event the T16 timer 644 times out before the BSC 105 returns a reset 
acknowledgment message to the aircore platform 200. 

The aircore platform 200 may interface with other wireless systems. To set up 
a call, trunks are established between the two systems. Figures 35-40 are flow charts 
that show the message traffic used to establish and reset the trunks. Figure 35 shows 
the message flows when a far end system sends a blocking request to the aircore 
platform 200. A blocking 700 is received from the BSC 105 and transferred to the 
REC 402. The REC 402 returns a REC.AMH_BLOCKING.ACK 703 to the BSC 105. 
The state of the trunk circuit established could move to blocked or to blocked pending 
depending on whether a call is currently on the channel. The REC 402 assures the 
appropriate state changes occur. 

Figure 36 shows the message flows for resetting a trunk circuit when no call is 
in progress. The BSC 105 sends a RESET.CIRCUrr 710 which is received at the 
REC 402. The REC 402 returns a REC_AMH_RESET_CIRCUITACK 714 to the 
BSC 105 and the circuit is reset. 

If a call existed on the trunk circuit, the message flows vary from that shown in 
Figure 36. Figure 37 shows the message flows in this situation. In Figure 37, the 
BSC 105 sends a RESETCIRCUIT 720, which is transferred to the REC 402. The 
REC 402 sends a REC.CPM_CLEAR.CALL 723 to the CPM 414. The CPM 414 
sends a CLEAR.C ALL 724 to the AMH 43 1 . The AMH 43 1 then clears the call. In 
parallel, the REC 402 sends a REC.AMH.RESET.CIRCUrr.ACK 725, which is 
transferred (726, 727) to the BSC 105. 

The trunk circuit may also be reset by action taken by the aircore platform 200. 
Figure 38 shows the message flows in this situation. The REC 402 initiates a 
REC.AMH_RESET.CIRCUrr 730, which is transferred (736, 738) to the BSC 105. 
The AMH 431 sets the T 12 timer 734 using an AMH.TMR.S ETTTMER (RESET. 
CIRCUIT) 733. The BSC 105 returns a reset circuit acknowledgment using 
RESET.CTRCUTT ACK 735, which is transferred (736, 738) to the REC 402. 
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1 Because the REC 402 received the reset circuit acknowledgment before expiration of 

2 the T12 timer 734, the AMH 43 1 sends (737) a timer release message to the TMR 437 

3 releasing the T12 timer 734. 

4 In some cases, the BSC 105 will not return a reset circuit acknowledgment 

5 message before expiration of the T12 timer 734. Message flows in this situation are 

6 shown in Figure 39. When the T12 timer 734 times out, AMH 431 (747) sends a time 

7 out message to the REC 402. The REC 402 then repeats the reset circuit procedure n 

8 number of times, where n is a setable parameter. When the nth attempt to reset the 

9 trunk circuit fails, an alarm is raised at the Operations and Maintenance system. The 

10 far end state of the circuit remains in an unknown state. 

1 1 Figure 40 shows the message flows associated with opening a trunk circuit. 

12 The message flows are similar to those in Figure 35. 

13 The aircore platform 200 maintains the current location of mobile customers 

14 using the VLR 422 and HLR 424. When a mobile customer enters the region serviced 

15 by the aircore platform 200, the mobile customer's mobile unit 112 will register with 

16 the aircore platform 200. Figures 41 through 47 show the message flows associated 

17 with this registration process. 

18 Figure 41 shows the message flows associated with the successful updating by 

19 location of a mobile unit 1 12. The flow assumes the mobile unit's profile has been 

20 previously retrieved and is stored in the VLR 422, and therefore no interaction is 

21 shown with the HLR 424. The BSC 105 sends (760) a location update request to the 

22 aircore platform 200. The request is received at the DH-7 510, which transfers (761) 

23 the update request. 

24 At the ARS 434, the update request triggers authentication processing if the 

25 mobile unit 1 12 operates according to IS-41 protocols. The update request is then 

26 passed (763, 764) to the VLR 422. The VLR 422 updates the active file for the 

27 mobile unit 112 and returns a VLR registration notification response to the BSC 105. 

28 When the VLR registration notification response reaches the ARS 434, GSM 

29 authentication and ciphering are completed, if the mobile unit 1 12 operates according 
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1 to GSM protocols. The BSC 105 receives a LOCATION.UPDATING.ACCEPT 769 

2 message from the DH-7 510. The DH-7 510 also provides a CLEAR_COMMAND 

3 771 to the BSC 105. At this time, GSM TMSI reallocation occurs. The BSC 105 

4 sends a CLEAR_COMPLETE 772 to- the DH-7 5 10, which in turn sends a DH-7_ 

5 AMH_TRANSFER 773 to the AMH 43 1 . 

6 Figure 42 shows the message flows associated with location updating in the 

7 event the registration notification request is rejected. Figure 43 shows the message 

8 flows if the mobile unit 112 powers down while operating in the vicinity of the aircore 

9 platform 200. 

10 Figure 44 shows the message flows associated with a periodic update in which 

11 the mobile unit 1 12 is already registered in the local VLR with the subscriber profile 

12 already having been retrieved from the HLR. The BSC 105 sends a LOCATION. 

13 UPDATE.. REQUEST 1400, which is transferred ( 1401 j to the AMH 43 1 . The AMH 

14 431 sends an AMH_ ARS .LOCATION JJPDATING.REQUES^ 1402 to the ARS 

15 434. At this point, authentication may be performed (1404) for IS-41 protocol 

16 equipment. The ARS 1406 then sends an ARS_IMH_AUTHENTICATION_ 

17 REQUEST 1406 to the IMH 432. The IMH 432 then sends an IMH_VLR_ 

18 REGNOT_REQUEST 1408 to the VLR 422. 

19 The mobile unit 112 was previously registered in the VLR 422. Therefore, the 

20 mobile unit's location is simply updated, and a VLR_IMHJREGNOT_RESPONSE 

21 1410 is returned to the IMH 432. The IMH 432 sends an IMH_ARS_ 

22 AUTHENTICATION„RESPONSE 1412 to the ARS 434, which in turn sends (1414) 

23 and authentication result to the AMH 43 1 . The AMH 43 1 then sends (14 16) a 

24 LOCATION JJPDATING_ACCEPT 1418 to the BSC 105. The aircore platform 200 

25 may also perform GSM authentication and ciphering (1413) and TMSI reallocation 

26 (1419). 

27 The AMH 431 sends (1421) a CLEAR.COMMAND 1420 to the BSC 105. 

28 The BSC 105 returns a CLEAR_COMPLETE 1422 to the DH-7 510, which sends a 

29 DH7_AMH_TRANSFER 1423 to the AMH 43 1 . 
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1 Figure 45 shows the message flows associated with location updating in which 

2 the mobile unit is not currently listed in the local VLR, but is listed in the local HLR. 

3 The initial message flows 1430 - 1438 are the same as shown in Figure 44 (1400 - 

4 1408), including authentication (1434) for IS-43 protocol systems. However, the 

5 mobile unit 1 12 is not listed in the VLR 422. The VLR 422 returns a VLR_IMH_ 

6 REGNOT_ RESPONSE 1440 that indicates the mobile unit 1 12 is not registered in 

7 the VLR 422. In response, the IMH 432 sends an IMH_HLR_REGNOT_REQUEST 

8 1442 to the HLR 424. The mobile unit 1 12 is registered in the HLR 424, and the HLR 

9 424 returns an HLR_IMH_REGNOT_ RESPONSE 1444- to the IMH 432. The IMH 

10 432 then sends an 1MH_VLR_ REGNOTJRESPONSE 1446 to the VLR 422 to 

1 1 register the mobile unit 1 12 in the VLR 422. In response, the VLR 422 returns a 

12 VLR_IMH_REGNOT_ RESPONSE 1448 to the IMH 432 to indicate that the mobile 

13 unit 1 12 is registered in the VLR 422. The remaining message flows (1450 - 1464) 

14 are similar to those (1412- 1422) shown in Figure 44. 

15 Figure 46 shows the message flows when the IMH 432 determines that the 

16 mobile unit 1 12 is homed to an external HLR. The IMH 432 makes this 

17 determination based on an identification of the mobile unit 1 12 that is provided with 

18 the initial location update request messages. In Figure 46, the initial message flows 

19 (1480 - 1488) are similar to those shown in Figure 44. The VLR 422 notifies the IMH 

20 432 that the mobile unit 1 12 is not registered in the VLR 422. Based on the 

21 identification of the mobile unit 1 12, the IMH 432 then determines that the mobile 

22 unit 1 12 is registered in an external HLR. The identification is used to locate the 

23 external HLR. The IMH 432 sends a MAP_UPDATE_LOCATION_INVOKE 

24 (GSM) or a REGISTRATION. NOTIHCATION_INVOKE (K-4 1 ) 1 492, 1493 to the 

25 external HLR. The IMH 432 also sets a REGNOT timer 1 496. The external HLR 

26 returns (1494) a MAP_UPD ATE_LOC ATION_RES ULT (GSM) or a 

27 REGIS TRAT10N_NOTinCATTON_RETTJRN .RESULTS (IS-41) 1495 to the MSC 

28 210. The IMH 432 releases the REGNOT timer 1496 and sends an IMH_VLR_ 

29 REGNOT.RESPONSE 1498 to the VLR 422, causing the mobile unit 1 12 to be 
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1 registered in the VLR 422. The VLR 422 then returns a VLRJMH_REGNOT_ 

2 RESPONSE 1499 to the IMH 432. The remaining message flows (1500 - 1509) are 

3 similar to those shown in Figure 44. 

4 Figure 47 shows the message flows when the IMH 432 determines that the 

5 mobile unit 1 12 is homed to an external HLR, but the REGNOT timer 1496 times out 

6 before the external HLR returns a response. The IMH 432 makes this determination 

7 based on an identification of the mobile unit 1 12 that is provided with the initial 

8 location update request messages. In Figure 47, the initial message flows (1510 - 

9 1524) are similar to those shown in Figure 46. When the REGNOT timer 1496 times 

10 out, the TMR 437 sends a TMRJMHJTIMER(REGNOT) 1525 to the IMH 432. The 

1 1 channel is cleared (1526 - 1535) in a manner similar to that in Figure 47. 

12 Figures 48-71 show the message flows associated with call processing. Figure 

13 48 is a flow chart for a mobile originated call. The mobile originated call begins when 

14 the BSC 105 receives an indication from the mobile unit 1 12 that the mobile unit 1 12 

15 will originate a call. The BSC 105 may receive the number of the called party that 

16 was dialed at the mobile unit 1 12. 

17 The BSC 105 transmits a CM,SERVICE_REQUEST 800 to the aircore 

18 platform 200 where the message is received and processed by the DH-7 5 10. The 

19 DH-7 510 establishes the SS-7 link and ensures proper message routing for the 

20 inbound message. The DH-7 510 sends a DH-7_AMH_TRANSFER 801 to the 

21 appropriate AMH 43 1 (either the GSM or the IS 634 thread). The AMH 43 1 sends an 

22 AMH.ARS.CM.SERVICE.REQUEST 802 to the ARS 434. 

23 The ARS 434 provides the appropriate calculations and processing to 

24 . authenticate the given base station interface. The ARS 434 then sends an 

25 ARS.IMH_AUTHENTICATION.REQUEST 803 to the appropriate IMH 432. The 

26 IMH 432 sends an IMH.VLR.REGNOT.REQUEST 804 to the VLR 422 to notify the 

27 VLR 422 of the incoming call. The VLR 422 registers the mobile unit 1 12 as an 

28 active unit and then sends a VLR_IMH.REGNOT_RESPONSE 805 to the appropriate 

29 IMH 432. The IMH 432 sends an IMH_ARS.AUTHENTICATION_RESPONSE 806 
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1 to the ARS 434. If the mobile unit 1 1 2 uses a GSM protocol, GSM authentication and 

2 ciphering are completed at this point. 

3 The ARS 434 sends an ARS.AMH AUTHENTIC ATION_RESULT 807 to the 

4 AMH 43 1 and the appropriate AMH 43 1 sends an AMH_DH-7_TRANSFER 808 to 

5 the DH-7 510. The DH-7 510 sends a CM_SERVTCE_ ACCEPT 809 to the BSC 105 

6 indicating to the BSC 105 that the mobile unit 1 12 is allowed to proceed with the call 

7 processing using the aircore platform 200. 

8 During the above-described processing for a GSM protocol mobile unit, the 

9 ARS assigns the call a temporary mobile subscriber identity (TMSI). The TMSI is 
calculated based on an index in the VLR 422, the time of day, and the identity (IMSI) 

1 1 of the mobile unit 1 12. The TMSI provides additional security so that if the mobile 

12 call is tapped, the identity of the calling mobile party cannot be determined. 

13 111 Figure 48, the mobile call process then proceeds to the call setup stage and 

14 the BSC 105 transmits a SETUP 8 10 to the DH-7 5 10. The SETUP 810 includes the 

15 call number and an identity of the mobile customer. The DH-7 510 transfers the 

1 6 information to the appropriate AMH 43 1 by sending a DH-7_ AMHTRANSFER 811. 

17 The AMH 43 1 then notifies the CPM 414 that a mobile originated call has been 

1 8 received by sending a CALL RECEIVED 8 1 2. When the CPM 4 14 is notified that the 

1 9 mobile call has been received, the CPM 4 14 allocates a voice channel for a mobile 

20 call to carry the voice between the aircore platform 200 and the BSC 105. The mobile 

21 call is assigned a session number and each party of the mobile call is assigned an 

22 object of the mobile call. 

23 The AMH 43 1 , the DH-7 5 10 and the BSC 105 communicate through a series 

24 of messages 8 13-82 1 that the call assignment request has been made and completed. 

25 During this processing, a T10 timer 818 is used to time out the call in the event a 

26 voice channel cannot be readily assigned. Once the channel assignment is complete 

27 and the radio and voice channels are assigned, the AMH 43 1 sends a ROUTE CALL 

28 822 to the CPM 414, informing the CPM 414 to proceed with the call because all of 

29 the incoming wireless communication requirements have been established. The CPM 
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1 414 determines, based on the number that is to be dialed out, what facility the call 

2 should go to and in what format. The CPM 414 sends a MAKE_CALL 823 to the 

3 appropriate device handler (DHD 50 1 , DHI 503 or DH-7 5 10) for a land-based or 

4 wired call. If the number to be dialed is for a mobile unit, the CPM 414 sends a 

5 location request (not shown) through the 1MH 432 to the HLR 424 to find out where 

6 the called mobile customer is. 

7 As shown in Figure 48, the device handler returns a CALL_ ALERTING 824 to 

8 the CPM 414 indicating an attempt to connect to the called party. The alerting 

9 message is then passed to the BSC 105 using an ALERT_CALL 825, AMHDH- 

10 7.TRANSFER 826 and an ALERTING 827. 

1 1 After the MAKE.CALL 823 is transmitted, the called party should return a 

12 signal to the appropriate device handler, which then sends a CALL_CONNECTED 

13 828 to the CPM 414. The CPM 414 sends a CONNECT.CALL 829 to the AMH 431, 

14 which propagates as a CONNECT 83 1 to the BSC 105. At the same time, the AMH 

15 431 sets a T3 13 timer 833 using a AMH TMR.SET TIMER (CONNECT) 832 to the 

16 TMR 437. The TMR 437 then waits for a connection acknowledgment that indicates 

17 the called party and the calling party are connected. In particular, the BSC 105 sends 

18 a CONNECT.ACK 834 to the DH-7 5 10, and the connect acknowledgment is 

19 propagated (835) to the AMH 431. The AMH 431 then releases the T313 timer 833 

20 by sending an AMHTMR.RECS TIMER (CONNECT) 836 to the TMR 437. At this 

21 point, the mobile originated call is connected. 

22 Figure 49 shows call processing for normal mobile termination. The aircore 

23 platform 200 receives a call at a device handler 501 or 503. The device handler sends 

24 a CALLRECEIVED 840 to the CPM 414. The CPM 414 forwards a CPM.IMH 

25 LOCATE.SUBSCRIBER 841 to the IMH 432 initiating a subscriber location action 

26 (not shown) in which the HLR 424 (not shown) is queried to determine the location of 

27 the called mobile unit 112. The IMH 432 returns an IMN.CPM.SUBSCRIBER. 

28 LOCATION 842 to the CPM 414 indicating the location of the mobile 1 12 unit within 

29 the wireless area served by the aircore platform 200. The CPM 414 then initiates a 



-63- 



WO 00/46938 



PCT/US00/02797 



1 CPM.PAG.PAGE.MOBILE 843 to the PAG 435 to page the called mobile unit 1 12. 

2 The called mobile unit 1 12 is then paged (845, 846) and returns a response (850-852). 

3 At the same time, the AMH 43 1 initiates a timer 855 that will timeout the page 

4 request if a page response from the mobile unit 1 12 is not received within a set time 

5 period. 

6 As shown in Figure 49, once the page response is received, the ARS 434 

7 initiates an ARSJMH. AUTHENTICATION.REQUEST 853 to the IMH 432. The 

8 IMH 432 sends an IMH.VLR.REGNOT REQUEST 854 to the VLR 422 to retrieve 

9 the profile information from the VLR 422 for the mobile unit 1 12. The VLR 422 

10 returns a VLRJMH REGNOT RESPONSE 857 containing the requested data for the 

1 1 mobile unit 1 12 in the VLR 422. 

12 During the time period that the mobile unit 1 12 is being paged and the 

13 authentication and registration notification messages are being passed, authentication 

14 and ciphering, may occur. In particular, for IS-41 protocol systems, authentication 

15 may occur at block 848. For GSM protocol systems, GSM authentication, ciphering 

16 and TSMI reallocation may occur at block 859. 

17 As shown in Figure 49, when the AMH 431 receives the authentication result, 

1 8 the AMH 43 1 initiates an AMHPAG.P AGE.RESPONSE 86 1 which is passed (862) 

19 totheCPM414. The CPM 414 then initiates a MAKE_CAUL 863. The aircore 

20 platform 200 then proceeds to call setup, channel assignment, alerting, call connection 

21 and call connection acknowledgment (864-889). 

22 Figure 50 shows a mobile terminated call in which no response is received to 

23 the PAGE_MOBILE message, and the page timer times out. In Figure 50, the 

24 messages 900-906 are similar to messages 840-846 of Figure 49. An 

25 AMH.TMR.SET. TIMER (P AGE.RESPONSE) 907 is sent by the AMH 43 1 to the 

26 TMR 437. When the AMH 43 1 fails to receive a response to the page request, the 

27 timer 908 times out in the TMR 437, and the TMR 437 sends a TMR_AMH TIMER 

28 (PAGE.RESPONSE) 910 to the AMH 431. The AMH 431 then initiates a series of 

29 messages 91 1 to 916 to update the VLR 422. The CPM 414 receives a PAGE CPM 
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1 PAGEJRESPONSE 918 indicating no response to the mobile page, and as a result the 

2 CPM 414 does not issue a MAKECALL message. 

3 Figure 51 shows the message flows associated with a PSTN initiated 

4 disconnect. The device handler (DHD 501 or DHI 503) receives a disconnect signal 

5 from a telephone or other device connected to the PSTN. The device handler sends a 

6 DIS CONNECT_C ALL 930 to the CPM 414, which returns a CLEAR_CALL 932 to 

7 the device handler and issues the CLE AR__C ALL to the AMU 932. As a result, a 

8 DISCONNECT (GSM) or RELEASE (IS-634) 934 is sent to the BSC 105, which 

9 returns a RELEASE (GSM) or RELEASE_COMPLETE (IS-634) 938. A T305 or 

10 T306 (GSM) or T308 (IS-634) timer 936 is also set in the TMR 437, and if the 

1 1 RELEASE or RELEASE_COMPLETE 938 is not received before expiration of the 

12 timer 936, the channel is released. 

13 Once the RELEASE or RELEASE_COMPLETE 938 is received, the AMH 

14 43 1 sends a CALL_CLEARED 944 to the CPM 4 14, and a RELEASE_COMPLETE 

15 943 is sent to the BSC 1 05. The DH-7 5 10 then sends a CLEAR_COMMAND 946 to 

16 the BSC 105, and an internal timer 948 is set in the TMR 437. The BSC 105 returns a 

17 CLEAR_COMPLETE 949, and the internal timer 948 is released. 

18 Figure 52 shows a mobile originated disconnect. A DISCONNECT (GSM) or 

19 RELEASE (IS-634) 960 is received at the DH-7 510 from the BSC 105. The DH-7 

20 510 transfers the message to the AMH 43 1, which initiates a DISCONNECTCALL 

2 1 962 to the CPM 414. The CPM 4 14 initiates a CLEAR.CALL 964 to the AMH 43 1 

22 and the device handler 501 or 503. The AMH 43 1 transfers (965) the CLEAR_CALL 

23 964 command to the DH-7 510, which initiates a release (GSM) or RELEASE. 

24 COMPLETE (IS-634) 966. The device handler 501 or 503 sends a CALLCLEARED 

25 967 to the CPM 4 14. The AMH 43 1 also initiates a T308 timer 964 (GSM) to clear 

26 the channel in case a RELEASE.COMPLETE message is not received from the 

27 mobile unit 112 within the time period set by the T308 timer 964. The BSC 105 

28 returns a RELEASE.COMPLETE (GSM) 970 to indicate that the mobile unit 1 12 has 

29 completed disconnect, and the AMH 43 1 releases the T308 timer 964 and sends a 
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1 CALL CLEARED 975 to the CPM 414. The AMH 43 1 sends an AMHDH- 

2 7.TRANSFER 967 to the DH-7 510, which initiates a CLEAR.COMMAND 977 to 

3 the BSC 105. The AMH 43 1 also sets an internal timer 980 to clear the channel in the 

4 event that a CLEAR_COMPLETE message is not received from the BSC 105. The 

5 BSC 105 then initiates a CLEAR.COMPLETE 978 and the AMH 43 1 releases (98 1) 

6 the internal timer 980. 

7 Occasionally, a base station may not return a response to the MSC 210 within 

8 the timeout specified. The message flows for this situation is shown in Figure 53. 

9 The message flow begins after the service request message flows shown in Figure 48 

10 (messages 800 - 809) are completed. A SETUP 960 is sent from the BSC 105 and in 

1 1 response, the AMH 43 1 sends a CALL_RECEIVED 991 to the CPM 414 and sets the 

12 T10 timer 818. Because the BSC 105 does not return a response to the 

13 ASSIGNMENT, REQUEST 996, the T10 timer 818 times out and the AMH 431 

14 sends a DISCONNECT_CALL 1000 to the CPM 414 to initiate a clear call sequence. 

15 The CPM 414 sends a CLEAR.CALL 1001 to the AMH 431, which is passed (1002) 

16 to the BSC 105 as a DISCONNECT (GSM) or RELEASE (IS-634) 1003. The AMH 

17 43 1 also sets (999) a channel release timer 936 in order to release the channel if the 

18 BSC 105 does not respond to the DISCONNECT 1003. 

1 9 The BSC 105 then sends a RELEASE (GSM) or RELEASE_COMPLETE (IS- 

20 634) 1004, which is transferred ( 1 005) to the AMH 43 1 . The AMH 43 1 releases 

21 (1006) the timer 936, sends a CALL_CLEARED 1007 to the CPM 414, and sends 

22 (1008) a RELEASE.COMPLETE 1009 (GSM) to the BSC 105. The AMH 43 1 then 

23 sends (1010) a CLEAR.COMMAND 1 01 1 to the BSC 105 and sets (1012) an 

24 internal timer 1013. The BSC 105 returns a CLEAR_COMPLETE 1014, which is 

25 transferred (1015) to the AMH 431, which then releases (1016) the internal timer 

26 1013. 

27 Figure 54 shows the sequence of a time out of the T10 timer 818 for a mobile 

28 terminated call. The initial message flows are the same as messages 840 - 860 shown 

29 in Figure 49 and are not repeated in Figure 54. The AMH 43 1 sends a 
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1 AMH_PAG_PAGE_ RESPONSE 1020 to the PAG 435, which is passed (1021) to 

2 the CPM 414. The CPM 414 sends a MAKE_CALL 1022, which is passed as a 

3 SETUP 1025 to the BSC 105. The BSC 105 returns a CALL_CONFIRMED 1027. 

4 The T303 timer 869 is set (1026) and released (1028, 1029). The BSC 105 receives 

5 an ASSIGNMENT_REQUEST 103 1 f and the AMH 43 1 sends an AMH_TMR_S ET_ 

6 TIMER (ASSIGNMENT_REQUEST) 1032 to set the T10 timer 818. However, the 

7 BSC 105 does not send a response to the AS SIGNMENT_REQUEST 1031, and the 

8 T10 timer 818 times out. As a result, the AMH 414 sends a DISCONNECT.CALL 

9 1036 to initiate tear down of the channel. The CPM 414 then sends a CLEAR_CALL 

10 1037, and the channel teardown proceeds through several message sequences to 

1 1 release the channel and to report that the call is cleared (1038 - 1054) in the same 

12 manner as shown in Figure 53. Coincident with the CLEAR_CALL 1037, the CPM 

13 414 may send the calling party an announcement to inform the calling party that the 

14 call cannot be completed to the mobile unit 112. 

15 Figure 55 shows the message flows associated with a mobile originated call 

16 when the channel assignment fails. Channel assignment failure can occur for a variety 

17 of reasons including when the BSC 105 and the MSC 210 do not agree on the state of 

18 the channel, for example. The BSC 105 and the MSC 210 will not agree on the state 

19 of the channel if the BSC 105 indicates the channel is blocked and the MSC 210 

20 indicates the channel is unblocked, for example. The BSC 105 also may incur a 

21 failure in the establishment of the radio portion of the connection. 

22 In Figure 55, a service request is initiated using the same message sequence 

23 (800 - 809) as shown in Figure 48. The BSC 105 then sends a SETUP 1060, which is 

24 received at the DH-7 510. The message is transferred (1061) to the AMH 43 1, which 

25 sends a CALL_RECEIVED 1062 to the CPM 414. The call proceeds through call 

26 setup (1063 - 1065) until an ASSIGNMENT_REQUEST 1066 is sent to the BSC 105. 

27 In this case, however, the BSC 105 returns an AS S IGNMENT_F AILURE 1070. As a 

28 result, the MSC 210 proceeds with call tear down (1071 - 1090) in the same manner 

29 as shown in Figure 53 (1002-1016). 
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1 Figure 56 shows the message flow associated with a mobile terminated call 

2 when the channel assignment fails. In Figure 56, the initial messages (840 - 860) 

3 shown in Figure 49 have already been completed. The AMH 431 then sends an 

4 AMH__PAG_PAGE_RESPONSE 1095 to the PAG 435, which passes the message 

5 (1096) to the CPM 414. The call setup phase begins with a MAKE_CALL 1097, a 

6 SETUP 1 101, a CALL„CONFIRMED 1 103 and an ASSIGNMENT_REQUEST 

7 1107. 

8 The BSC 105 returns an AS SIGNMENT_FAILURE 1 109, indicating, for 

9 example, that the BSC 105 and the MSC 210 do not agree as to the state of the 

10 channel allocated between the BTS and the MSC 210. The AMH 431 sends a 

1 1 DISCONNECT.CALL 1 1 12 to the CPM 414, which returns a CLEAR_CALL 1115. 

12 Call tear down then proceeds in the same manner as shown in Figure 53. 

13 Figure 57 shows the message flows associated with a call disconnect when the 

14 CLEAR_COMMAND internal timer times out. For the PSTN initiated disconnect 

15 and the mobile originated disconnect, the message flows are the same once the 

16 CALL„CLEARED 1 135 is sent by the AMH 43 1 to the CPM 414. The AMH 43 1 

17 sends (1 136) a CLEAR_COMMAND 1 139 to the BSC 105 and sets (1 137) a 

18 CLEAR„COMMAND internal timer 1 138. The BSC 105 does not respond with a 

19 CLEAR_COMPLETE message, and the internal timer 1 138 times out (1 140) 

20 releasing the channel. 

21 Figure 58 shows the message flows when the MSC 210 rejects a CM service 

22 request. The BSC 105 sends a CM_SERVICE_REQUEST 1 145 to the MSC 210. 

23 The DH-7 510 determines the protocol of the sending mobile unit 1 12 and spawns an 

24 appropriate thread and forwards (1 146) the CM_SERVICEJREQUEST 1 145 to the 

25 AMH 43 1 . The AMH 43 1 sends an AMH_ARS_CM_SERVICE_REQUEST 1 147 to 

26 the ARS 434, which forwards an ARS_IMH_AUTHENTICATION_REQUEST 1 148 

27 to the IMH 432. The ARS in turn sends a registration notification (IMH_VLR_ 

28 REGNOT_REQUEST 1 149) to the VLR 422. The VLR 422 returns a response 

29 (1 150) that rejects the service request. This response is passed (1 15 1) to the ARS 
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1 434, which sends a CM_SER VICE_REQUEST 1 1 52 to the AMH 43 1 . The AMH 

2 431 transfers (1 153) the rejection to the BSC 105 as a CM_SERVICE_REJECT 1 154. 

3 Figure 59 shows the message flows associated with a mobile terminated call in 

4 which the CPM 414 times out waiting for an alerting message from the AMH 43 1 . 

5 The initial message flows are the same as shown in Figure 49 (i.e., 840 - 860). The 

6 AMH 43 1 sends (1 155) a page response to the PAG 435, which forwards ( 1 156) the 

7 page response to the CPM 4 14. The CPM 414 sends a MAKE_CAUL 1 157 to the 

8 AMH 431, which transfers (1158) the message as a SETUP 1 159 to the BSC 105. 

9 The CPM 414 also sets the T310 timer 876, waiting on receipt of an alerting message. 

10 The BSC 105 returns a CALL_CONFIRMED 1 165, which is passed (1 166) to the 

1 1 AMH 431. A channel assignment is then completed (1 168 - 1 172). However, the 

12 BSC 105 does not send an alerting message to the MSC 210, and the T3 10 timer 876 

13 times out in the CPM 414. As a result, the CPM 414 sends a CLEAR^CALL 1 173 to 

14 the AMH 43 1, which is passed (1 174) to the BSC 105 as a DISCONNECT (GSM) or 

15 a RELEASE (IS-634) 1 175. The call tear down then proceeds (1210-1226) in the 

16 same manner as shown in Figure 53 (1002 - 1016). 

17 Figure 60 shows the message flows associated with a mobile terminated call in 

18 which the call confirmed timer times out in the TMR 437. The initial message flows 

19 are the same as those shown in Figure 49 (840 - 860). The AMH 43 1 sends an 

20 AMH_PAG_PAGE_RESPONSE 1200 to the PAG 435, which forwards (1201) it to 

21 the CPM 414. The CPM 414 sends a MAKE„CALL 1203 to the AMH 43 1 and sets 

22 the T3 10 timer 876. The AMH 43 1 transfers (1204) the MAKE_CALL 1203 to the 

23 BSC 105 as a SETUP 1205 and sets (1206) the T303 call confirmed timer 869 in the 

24 TMR 437. However, the BSC 105 does not return a call confirmed message to the 

25 MSC 210, and the T303 timer 869 times out (1207). The AMH 431 sends a 

26 DISCONNECT.CALL 1208 to the CPM 414 and the CPM 414 responds with a 

27 CLEAR_CALL 1209. The call tear down then proceeds (1210-1226) in the same 

28 manner as shown in Figure 53 (1002 - 1016). 
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1 Figure 61 shows the message flows associated with a mobile terminated call in 

2 which the call connect timer times in the CPM 414. The initial message flows are the 

3 same as those shown in Figure 49 (840 - 860). The AMH 431 sends an 

4 AMHJPAG„PAGE_RESPONSE 1230 to the PAG 435 and call set up proceeds 

5 through make call, call confirmed and channel assignment (123 1 - 1245). The BSC 

6 105 then sends an ALERTING 1246, which is transferred (1247) to the AMH 431. 

7 The AMH 43 1 sets (1248) a T301 call connected timer 883 in the CPM 414. 

8 However, the BSC 105 does not return a connect message, and the T301 timer 883 

9 times out. The CPM 414 sends a CLEAR_CALL 1250 to the AMH 43 1, and call tear 

10 down proceeds in the same manner as shown in Figure 53 (1002 - 1016). 

1 1 Figure 62 shows the message flows associated with a mobile originated call in 

12 which the BSC 105 does not send a connect acknowledge message to the MSC 210 

13 and the T313 connect acknowledge timer 833 times out. The initial message flows are 

14 the same as shown in Figure 48 (800 - 809). The call proceeds through setup, channel 

15 assignment, alerting and call connection (1270 - 1294). The AMH 431 sets (1293) the 

16 T313 connect acknowledge timer 833. However, the BSC 105 does not return a 

17 connect acknowledgment, and the T3 13 timer 833 times out (1297). The MSC 210 

18 then proceeds through call tear down. 

19 Figure 63 applies to GSM and IS-634. Figure 63 shows the message flows 

20 associated with a call disconnect (mobile or PSTN originated) in which the T308 

21 (GSM) release complete timer 964 times out. Similar message flows would exist for 

22 IS-634 protocol equipment. The initial message flows are the same as shown in 

23 Figure 51 or Figure 52. The CPM 414 sends a CLEAR_CALL 1300 to the AMH 431, 

24 which is transferred (1301, 1302) to the BSC 105. The AMH 431 also sets (1303) a 

25 T308 release complete timer 964. As shown in Figure 63, the BSC 105 does not 

26 return a release complete message and the T308 timer 964 times out (1304). The 

27 AMH 431 then sends (1305) a second RELEASE 1306 to the BSC 105 and sets 

28 (1307) a second T308 timer 964\ The BSC 105 returns a RELEASE_COMPLETE 

29 1 308, and the AMH 43 1 releases ( 1 3 1 0) the T308 timer 964\ If the T308 timer 964' 
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1 were to expire, the AMH 431 could release the transaction and send a call cleared 

2 message to the CPM 414. The MSC 210 may then go through a call clear sequence. 

3 Returning to Figure 63, the AMH 43 1 next sends a CALL_CLEARED 13 15 to the 

4 CPM 414, sends (13 16) a CLEAR_COMMAND 1317 to the BSC 105, and sets 

5 (1318) a clear command internal timer 1319. The BSC 105 returns a 

6 CLEAR_COMPLETE 1320 to the MSC 210. The AMH 431 then releases the 

7 internal timer 1319. 

8 Figures 64-66 show the message flows associated with processing a dual tone 

9 multiple frequency (DTMF) signal. As shown in Figures 64 - 66, the BSC 105 

10 initiates the processing by sending a START_DTMF (1330 in Figure 64) and the 

1 1 CPM 414 returns a CPM_ AMH__S T ART_DTMF_ A C K (1333 in Figure 64). 

12 Figures 67-71 are flow charts showing message handling associated with call 

13 processing with an HLR (internal or external). 

14 Figure 67 shows the message flows when an incoming call is received at the 

15 MSC 210, a location request is sent to the HLR 424, and the HLR 424 indicates that 

16 the mobile unit 1 12 is operating locally. The DHI 501 sends a CALL_RECEIVED 

17 1536 to the CPM 414. The CPM 414 sends a CPMJMH_LOCATE__SUBSCRIBER 

18 1537 to the IMH 432. The IMH 432 then sends an IMH_HLR_LOCATION_ 

19 REQUEST 1538 to the HLR 424. The HLR 424 returns a response (1539) indicating 

20 that the mobile unit 1 12 is homed on the local system and is operating locally. The 

21 IMH 432 then provides an IMH_CPM_SUBSCRIBER_LOCATION 1540 to the CPM 

22 414 indicating that the mobile unit 1 12 is operating locally. The remaining message 

23 flows 1541 - 1595 are similar to those shown in Figure 49. 

24 Figure 68 shows the message flows associated with an incoming call to a 

25 mobile unit 112 that is operating locally but is homed on an external HLR. The DHI 

26 503 sends a CALL.RECEIVED 1600 to the CPM 414, which sends a CPM_EMH_ 

27 LOCATE_SUBSCRIBER 1602 to the IMH 432. Because the mobile unit 1 12 is not 

28 homed locally, the IMH 432 sends a location request 1600/1608 to the external HLR 

29 and sets (1604) a LOCREQ timer 1605. The IMH 432 then receives a return 
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1610/1612 from the external HLR and releases (1614) the LOCREQ timer 1605. 
Then the EMH 432 sends an IMH_CPM_SUBSCRIBER_LOCATION 1616 to the 
CPM 414 indicating the location of the mobile unit's 1 12 HLR. The remaining 
message flows 1620 - 1699 are similar to those in Figure 49. 

Figure 69 shows the message flows associated with call processing for a 
mobile termination in which the mobile unit 1 12 is homed on the HLR 424 but is 
operating externally to the wireless network controlled by the aircore platform 200. In 
this case, the mobile unit 1 12 will be registered on an external VLR. The CPM 414 
receives a CALL_RECEIVED 1700 and sends a location request 1702 to the IMH 
432. The IMH 432 sends a location request 1704 to the HLR 424. Because the 
mobile unit 1 12 is registered on another wireless network, the HLR 424 sends a route 
request 1706 to the IMH 432, which sends an invoke 1710 to the external VLR and 
sets a ROUTEREQ timer 1709. The external VLR returns the results 1712 to the 
IMH 432, and the IMH 432 releases the ROUTEREQ timer 1709. The IMH 432 also 
sends an IMH_HLR_ROUTE_REQUEST_RESPONSE 1716 to the HLR 424 and the 
HLR 424 returns a location response 1718. The IMH 432 then sends (1720) the 
location of the mobile unit 1 12 to the CPM 414, which issues a MAKE_CALL 1722 
to the roaming number provided by the external wireless network serving the mobile 
unit 112. The process then proceeds through call alerting and call connection. 

Figure 70 shows the message flows for call processing for a mobile terminated 
call when the mobile unit 1 12 is homed on an external HLR and is operating 
externally to the wireless network controlled by the aircore platform 200. The CPM 
414 receives a CALL__REQUESTED 1730 from the DHD 501. The CPM 414 then 
sends a CPM_IMH_LOCATE_S UBS CRIB ER 1732 to the IMH 432. The IMH 432 
sets a timer 1734 and sends an invoke message 1736 to the DH-7 510. The DH-7 510 
sends 1736 the invoke message to the external HLR and receives (1738) a response. 
The DH-7 510 then sends a results message 1739 to the IMH 432. The remaining 
message flows are similar to those shown in Figure 69. 
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1 Figure 7 1 shows the message flows associated with call processing for a 

2 mobile unit 1 12 homed on an external HLR but operating within the wireless network 

3 controlled by the aircore platform 200. In this scenario, the mobile unit 1 12 receives a 

4 call that goes initially to the MSC of the external wireless network. The call is then 

5 routed to the wireless network controlled by the aircore platform 200. The MSC 210 

6 receives an invoke message 1751 from the external HLR. The IMH 432 then sends a 

7 route request 1752 to the VLR 422. Because the mobile unit 1 12 is roaming, it will be 

8 registered on the VLR 422. The VLR 422 returns a route request response 1 753 to the 

9 IMH 432, which sends a roaming number 1754 to the external HLR indicating the 

10 location of the HLR 424. The remaining message flows are similar to those in Figure 

11 49 with the exception that the IMH 432 does not have to locate the mobile unit. 

12 Figure 72 shows the message flows associated with hand off pre-processing 

13 for an ISDN PRI+ protocol. The BSC 105 sends a HANDOFFJREQUEST 1850 to 

14 the DHI 503, which sends a HANDOFFJREQUEST 1852 to the HOP 416. The HOP 

15 416 returns a MEASUREMENT_REQUEST 1854 to the DHI 503, which sends a 

16 HANDOFF_MEASUREMENT_REQUEST 1856 to the BSC 105. The HOP 416 also 

17 sends measurement requests (1854yi856*) to all base stations capable of handling the 

18 message traffic from the mobile unit for which the hand off is requested. The BSC 

19 105 returns a HANDOFF_MEASUREMENT_RESPONSE 1858 to the MSC 210, and 

20 a MEASUREMENT_RESPONSE 1860 is sent to the HOP 416. Other base stations 

21 likewise return measurement responses (1858\ I860 1 ) to the MSC 210. The HOP 416 

22 then proceeds with the handoff process. Figure 72 shows the initial message 

23 responses for the ISDN PRI+ protocol. Other protocols use similar initial 

24 measurement flows to establish a target base station for hand off. 

25 Wireless customers can pay for their services in a variety of ways including an 

26 annual subscription and on a monthly basis, for example. In both these cases, the 

27 customer pays for the call actually made (air time) plus a periodic base fee. 

28 Customers can also pay for wireless services in advance through a prepaid system. 

29 Figure 73 is a logical diagram of an aircore prepaid rating system 2100. The aircore 
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1 prepaid rating system 2100 includes a data management module 2101, a rating 

2 administration module 2102, a distributor data module 2103, and distributor rate plans 

3 21 10 through 21 19. Thus, a distributor can have up to ten different rate plans. Each 

4 customer can select one of the ten different rate plans for each distributor in the 

5 aircore prepaid rating system 2100. 

6 The distributor can be viewed much like a class of service is viewed in 

7 routing. The distributor is a classification of rating service that is assigned to certain 

8 groups of subscribers in the aircore system; A distributor could be a point of sale, a 

9 corporate customer, or an operator classification for a group of customers. Within 

10 each distributor, there can be up to ten different rate plans configured. A rate plan 

1 1 establishes the air time rates for the plan. The combination of distributor and rate plan 

12 provide a comprehensive rating schedule for a variety of combinations within the 

13 system. 

14 Within each customer profile 460 (see Figure 20) in the aircore HLR 424, the 

15 parameter for prepaid service is configured as prepaid or not. The prepaid 

16 configuration of the customer is controlled via a prepaid check box and associated 

17 prepaid window and a graphical user interface (see Figure 89). The window is used to 

18 define the distributor and rate plan that the customer uses for the prepaid service. 

19 Also, the credited amount for the account is input with the prepaid data. This field 

20 tracks the amount of service that a customer is allowed on the system. The amount is 

21 updated in real-time to track the usage of the system by the customer. 

22 A third part of the prepaid system is bill generation that is integrated as part of 

23 a call record management subsystem. The set of functions available allows the 

24 operator the ability to create a range of reports based on operator defined billing 

25 cycles. 

26 In operation, when a customer who has elected a prepaid plan uses the aircore 

27 prepaid rating system 2100, the customer profile 460 is pulled from the HLR 424 to 

28 determine the applicable distributor rate plan. The information from the customer 

29 profile 460 is passed to the CPM 414. The CPM 414 determines if the customer has 
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1 an account balance sufficient to pay for the call. The CPM 414 also determines the 

2 least cost route for the call, including defining the land charge and the air time charge 

3 associated with the destination and time of day of the call to come up with the per 

4 minute charge. This value is then used to set a timer that will indicate when the 

5 customer's account reaches a balance that corresponds to two minutes left on a call. 

6 Once the prepaid call has begun, the timer begins a time out process and when 

7 the two minute position is reached, a tone warning is provided to the customer 

8 indicating that the customer is running out of money. No further warnings are 

9 provided, and once the next two minutes have expired, the TMR 437 sends a message 

10 to the CPM 414 indicating that the time has expired. The CPM 414 then initiates a 

1 1 . call cutoff, terminating the prepaid call. In this way, the customer cannot overrun the 

12 prepaid account balance 

13 At the completion of the call, the billing system 260 calculates how much the 

14 call actually cost for the customer and updates the amount in the HLR 424. A call 

15 detail record (CDR) is prepared that provides the detailed information regarding the 

16 call so that the billing system 260 can determine the remaining account balance. The 

17 bill generated by the billing system 260 is then used to update the customer profile 

18 460. 

19 In the wireless environment shown in Figure la- Id, there may be a need to 

20 locate customers who place distress, or emergency (911), calls. These 911 calls are 

21 used to gain rapid access to local authorities and emergency service centers, if a 

22 customer places a 9 1 1 call from a wired device, locating that customer is easy using 

23 call tracing procedures. Customers using wireless devices are more difficult to locate. 

24 The air core platform 200 solves the problem of wireless customer location by 

25 creating an identification number based on the current position of the customer in the 

26 wireless environment. The aircore platform 200 uses the identification number as the 

27 dialed number to route the call to an emergency service center. The identification 

28 number includes the position data available from the BSS where the call origination is 

29 received. The location information received from the BSS is coded in hexadecimal. 
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1 The aircore platform 200 converts the hexadecimal number to binary coded decimal 

2 (BCD) and uses this number as an indication of the customer's location. 

3 Following is an example of the data conversion used by the aircore platform 

4 200 to convert the location data received from the BSS 1 10 to a dialed number for 

5 emergency callers. The data received could be as shown in the following table in 

6 which the BSS 110 receives the location of a customer with cell ID granularity. The 

7 MSC 210 converts the data as shown in the table. 



8 


FIELD 


RESULTING NUMBER OF DIGITS 


9 


Mobile Country Code 


Up to 3 


10 


Mobile Network Code 


Up to 3 


11 


Location Area ID 


Up to 3 


12 


Cell ID 


Up to 3 



13 The numbers produced from the conversion yields a unique 12 digit number 

14 identifying that cell in the system. 

15 The aircore platform 200 may incorporate the concept of customer groups to 

16 define the routing translations (classes of service) for the wireless network. A 

17 customer group is a table of number ranges that is used to determine if a call is 

18 allowable. The aircore platform 200 searches the list of entries in the table. If a 

19 match is found, the call is allowed to proceed. If a match is not found, the call is not 

20 allowed to proceed in the wireless network. 

21 The aircore platform 200 allows for the definition of up to 256 different 

22 customer groups. Each customer in the system, and each trunk, is associated with a 

23 customer group when a customer group is initially configured. The customer group 

24 that is used for a particular call is determined based on: 1) the customer placing the 

25 call; and 2) the trunk that received the call. 
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1 For emergency calls, a specific customer group is used to provide the routing 

2 translations. For emergency calling, the aircore platform 200 uses emergency 

3 translations. 

4 Figure 74 is a flow diagram illustrating emergency call processing using the 

5 aircore platform 200. The processing starts as step S100. In step SI 10, the call is 

6 received at the aircore platform 200. The process then moves to step S 120. In step 

7 S 120, the aircore platform 200 determines if the call is an emergency call. If the call 

8 is not an emergency call, the process proceeds to step S 130 and the call is handled as a 

9 normal call. In step S 120, if the call is an emergency call, the process moves to step 

10 S 140. In step S 140, the aircore platform 200 converts the location of the mobile unit 

11 to a dial-up number. The process then moves to step S 150. 

12 In step S 150, the aircore platform 200 checks the portion of the customer 

13 group associated with emergency calls. The process then moves to step S 160. In step 

14 S 160, the aircore platform 200 determines if the dial-up number from step S140 is in 

15 the customer group. If the dial-up number is not in the customer group, the process 

16 proceeds to step S 170, and the call is routed to a default emergency center. If the dial- 

17 up number is the customer group, the process moves to step S 180. In step S 180, the 

18 aircore platform 200 changes the dial-up number to an emergency center number. The 

19 process then moves to step S 190. In step S 190, the call is routed to the emergency 

20 center. The process then moves to step S200 and ends. 

21 The aircore platform 200 can also support other communication features. For 

22 example, the aircore platform 200 may be used with a long-distance resale system. 

23 The aircore platform 200 can also be used to provide microcellular wireless 

24 networks in combination with land-line local networks or private branch exchanges 

25 (PBX). There are several standards including computer supported 

26 telecommunications applications (CTSA), windows telephony application 

27 programming interface (TAPI), and telephony services application programming 

28 interface (TSAPI), for example, that allow a PBX to incorporate equipment and 

29 features from outside vendors. These protocols also allow for call control and routing 
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1 decisions to be made by a system that is external to the PBX. The external system can 

2 be used to allow for connectivity, feature processing, and seamless number 

3 management that allows customers to use both the PBX infrastructure and a separate 

4 wireless system using one telephone number and one customer feature profile. 

5 The aircore platform 200 provides an external control function to integrate a 

6 wireless system, or microcell, and a PBX using the technique of third party call 

7 control. Figure 75 is a diagram illustrating first party call control. In Figure 75, an 

8 application 2010 controls a call from a PBX 201 1 to a telephone 2014. The control of 

9 the call is related to each of the signals and messages passed between the telephone 

10 2014 and the PBX 201 1. First party call control is often used as a call control feature 

1 1 in private branch exchanges. 

12 Figure 76 illustrates third party call control. In Figure 76, a call control 

13 application 2015 provides direct control over termination of a call to the resource such 

14 as the telephone 2014. Calls into a PBX 2016 are routed under the control of the call 

15 control application 2015. The aircore platform 200 can incorporate the concept of 

16 third party call control to add on to the functionality of a PBX. In particular, the 

17 aircore platform 200 may be used with a PBX to add in-building wireless 

18 communication capabilities to an existing wired private branch exchange. 

19 A standard PBX interface control element (SPICE) may be added to the 

20 aircore platform 200 to provide an interface to a PBX. The SPICE includes software 

21 that can operate with the control protocols of different PBXs. The SPICE interfaces 

22 internally with the HLR 424 and the SCR 3 14 (see Figure 10). A system operator may 

23 interface with the SPICE using a graphical user interface (GUT). 

24 The SPICE provides third party call control messaging needed to provide the 

25 notice of an incoming call, decide how to handle the incoming call and send the 

26 appropriate commands to route the incoming call to the correct destination. The 

27 SPICE may be co-located with the HLR 424, and requires the basic retrieval 

28 capabilities of the HLR 424. The customer profile information in the HLR 424 allows 

29 the SPICE to determine how to handle a call. For example, the customer profile may 
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1 indicate the operational modes for the customer's wired and wireless telephone 

2 handsets. 

3 Customers whose PBX incorporates wireless features, including the SPICE, 

4 noted above, may designate one or more operational modes for their telephone 

5 handsets. Customers may elect to have incoming call terminate at their desktop 

6 telephone first. If the desktop telephone is not available, the call may be routed, via a 

7 MSRN, to the customer's mobile unit. Second, the call may be first routed to the 

8 mobile unit. If the mobile unit is not available, the call may be routed to the desktop 

9 telephone. Third, the call may be routed to the customer's mobile unit only. Fourth, 

10 the call may be routed to the customer's desktop telephone only. Fifth, the call may 

11 be routed to the mobile unit only when operating in the mobile unit's 112 home area. 

12 One advantage of this arrangement is that the HLR 424 may house the full 

13 suite of call forwarding features, voice mail and announcements. The customer's 

14 profile determines how the call is handled. 

15 If the customer profile indicates that incoming calls are first routed to a mobile 

16 unit, the HLR 424 will locate the customer in the telecommunications network and 

17 then have an MSRN allocated to deliver the call to the switch where the customer's 

18 mobile unit is residing. 

19 If the customer profile lists the desktop telephone as the first call delivery 

20 option, the SPICE determines that the call should be terminated to the desktop 

21 telephone. If the customer answers the desktop telephone, SPICE' s involvement in 

22 the call ends. However, if the customer does not answer at the desktop telephone, 

23 SPICE processing can determine the appropriate handling for the call. The call could 

24 be routed to the mobile unit, voice mail, or an announcement, for example. 

25 Figures 77 - 79 illustrate call routing for various call entry points. In Figure 

26 77, a PBX 2020 receives an incoming call from a PSTN (not shown). The PBX 2020 

27 uses third party call control over a CSTA interface (not shown) to notify (2022) a 

28 HLR 2030 that a customer has received an incoming call 2021. The HLR 2030 

29 determines that the customer is currently roaming on another wireless telephone 



-79- 



BNSDOCID: <WO 0O46938A1J > 



WO 00/46938 PCT/US00/02797 



1 system, and that the call needs to be delivered to the customer. Using standard mobile 

2 application messaging, the appropriate number for the delivery is allocated and sent 

3 (2023) to the PBX 2020. Via the CSTA interface, the PBX 2020 is commanded to 

4 send the call over the PSTN with the delivery number as the destination. The call 

5 arrives at a local MSC 2025 and is delivered (2037, 2038) via a wireless network 2035 

6 to a mobile unit 2036. 

7 Figure 78 shows a scenario for call delivery to the mobile unit 2036 when the 

8 local MSC 2025 is the point of entry for the call from the PSTN (not shown). An 

9 incoming call 2040 is received from the PSTN at the local MSC 2025. The MSC 

10 2025 communicates (2041) with the HLR 2030 for call delivery information. The 

1 1 HLR 2030 determines that the customer is roaming on another wireless network 2035 

12 and that the call should be delivered to the wireless network 2035. The appropriate 

13 number for delivery is allocated and sent (2039) to the MSC 2025. The MSC 2025 

14 then delivers (2042, 2043) the call to the mobile unit 2036. 

15 Figure 79 shows a scenario for call termination to a desktop telephone. In 

16 Figure 79, the local MSC 2025 receives an incoming call 2045 from the PSTN (not 

17 shown). The MSC 2025 communicates with the HLR 2030 for call delivery 

18 information. The HLR 2030 determines that the customer is not registered in the 

19 wireless network 2035 and determines that the call should be terminated to the PBX 

20 2020. The HLR 2030 allocates (2047) a delivery number for the PBX 2020. Using 

21 standard procedures, the HLR 2030 sends the delivery number to the MSC 2025. The 

22 MSC 2025 then delivers (2048) the call 2045 to the PBX 2020. Using third party call 

23 control, the HLR 424 associates the call 2045 with a customer and the call 2045 is 

24 terminated to the desktop telephone 2014. 

25 Figure 80 shows an aircore platform 2200 that is used to provide an in- 

26 building wireless and wired telephone system with third party call control. A building 

27 2210 includes a PBX 221 1. The PBX 221 1 connects to wired telephones 2212. The 

28 building 2210 also includes a microcellular wireless network 2201 serving mobile 

29 units 2213. The PBX 221 1 connects to the aircore platform 2200 via wired a 



-80- 



WO 00/46938 



PCT/US00/02797 



1 connection and a suitable interface such as a RS-232 interface. The aircore platform 

2 2200 includes a base station controller 2206 and a suitable interface to provide 

3 wireless communication to the microcellular network 2201. The BSC 2206 may be 

4 incorporated as a component on a card in the aircore platform 2200. A separate 

5 database 2205, containing information related to customers of the building 2210 may 

6 be provided with the aircore platform 2200. Alternately, the data may be included in a 

7 home location register in the aircore platform 2200. Finally, macro cellular systems, 

8 such as the extended wireless network 2220 with cells 2221 and 2222 may exist 

9 external to the microcell 220 L 

10 In operation a customer using both a wired telephone 2212 and a mobile unit 

11 2213 may specify, by entry in the database 2205, for example, which of the wired 

12 telephone 221 1 and mobile unit 2213 should receive a call. Thus, when a call comes 

13 in to a particular customer, the aircore platform 2200 will determine which of the 

14 wired telephone 2212 and the mobile unit 2213 to connect to first. The aircore 

15 platform 2200 can be further instructed that when the mobile unit 2213 is active, or in 

16 a power-on state, all calls should first be routed to the mobile unit 2213. If the mobile 

17 unit 2213 does not respond after a certain number of rings, the incoming call can then 

18 be routed to the wired telephone 2212. The microcellular network 2201 may also be 

19 used for visitors to the building 2210. In this case, a visitor having a mobile unit may 

20 have that mobile unit initiate a registration notification when the mobile unit enters 

21 the microcellular network 2201. Then, any incoming calls to the visitor's mobile unit 

22 will be routed through the aircore platform 2200 to the microcellular network 2201. 

23 When a customer of the building 2210 transits from the microcellular network 

24 2201 to the external wireless network 2220, a location update is performed that 

25 deletes the customer's location in a VLR of the microcellular network 2201, and 

26 initiates a registration notification with the mobile switching center of the external 

27 wireless network 2220. In this way, the exact location of the mobile unit 2213 may be 

28 maintained so that calls to a particular customer may be routed in accordance with the 

29 customer's routing plan contained in a VLR/HLR or the database 2205. 
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1 In the arrangement described above, a particular mobile unit 2213 and wired 

2 telephone 2212 may share a common telephone number. In an alternate arrangement, 

3 the wired telephone 2212 and mobile unit 2213 may have different telephone 

4 numbers. 

5 A microcellular network, such as the microcellular network 2201, may also be 

6 adapted for use in large buildings, such as indoor stadiums and convention centers. A 

7 mobile switching center such as the aircore platform 2200 may incorporate multi- 

8 protocol processing and base stations so that visitors to the convention center may use 

9 mobile units inside the convention center regardless of the protocol established for the 

10 mobile unit. The aircore platform 2200 may be configured to charge different rates 

1 1 for different visitors to the convention center. People who work in the convention 

12 center may be charged yet another rate for using mobile units in the convention center. 

13 The aircore platform 200 may incorporate fault resilient features, which may 

14 be particularly desirable for distributed wireless systems. The fault resilient hardware 

15 architecture of the aircore platform 200 may be logically split into three layers as 

16 shown in Figure 81. A hardware architecture 2300 includes a computing element 

1 7 layer 23 1 0. The computing element layer 2310 includes computing elements 2311 

18 and 2312. The computing elements 231 1 and 2312 are connected by an appropriate 

19 communications medium such as an ethemet 23 13. The ethernet 23 13 may have a 

20 capacity of 100 Mb or more, for example. 

21 An input/output (I/O) processor layer 2320 includes I/O processors 2321 and 

22 2322. The I/O processors 2321 and 2322 are connected by an appropriate 

23 communications medium such as a 100 Mb ethemet 2323. The I/O processors 2321 

24 and 2322 are both connected to each of the computing elements 23 1 1 and 2322 by an 

25 appropriate communications medium such as a 40 Mb fiber optic cable 23 14. 

26 A telephony interface processor (TIP) layer 2340 includes a plurality of 

27 telephony interface processors (TTPs) 2341 , - 2341 n . The TIPs 2341 , - 2341 n are - 

28 connected by a dual rail ethernet 2343. The ethernet 2343 is also used to connect the 

29 TIPs 2341, - 2341 n with the I/O processors 2321 and 2322. 
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1 The three layers described above comprise the three main processing areas of 

2 the aircore platform 200. Communications between the three layers provides for a 

3 variety of physical layouts and geographical configurations. For example, the fiber 

4 optic connection between the computing element layer 23 10 and the I/O processor 

5 layer 2320 can be geographically separated by 1.5 kilometers or more. The TIPs 

6 2341 , - 234 l n can be spread geographically and remotely controlled via a centralized 

7 computing element layer and I/O processor layer set. Thus, the aircore platform 

8 architecture 2300 can be adapted to provide a large distributed wireless network with 

9 centralized control or the layers can be co-located. 

10 Figure 82 shows the logical construction of the computing element 231 1 in 

1 1 more detail. The computing element 23 12. is identical to the computing element 23 1 1 

12 and therefore, only the computing element 23 1 1 will be described. The computing 

13 element 231 1 includes a central processor 23 15, a memory 2316 and a PCI-based 

14 connector 23 17 that couples the computing element 23 1 1 to the I/O processors 2321 

15 and 2322. Also shown is a memory 23 18 that stores the software applications that 

16 operate in the computing element 23 1 1 . The software applications are described with 

17 reference to Figure 10. The memory 23 16 may be a random access memory (RAM), 

18 for example. The memory 2318 may be a read only memory (ROM), for example. 

19 Figure 83 shows the logical construction of the I/O processor 2321 in more 

20 detail. The I/O processor 2322 is identical to the I/O processor 2322 and therefore 

21 only the I/O processor 2321 will be described. A PCI interface 2332 connects the I/O 

22 processor 2321 to the ethernet 23 14. A memory module 2326 includes a hard disk 

23 2327, an interface slot 2328 for a CD-ROM, and an interface 2329 for a floppy disk. 

24 A memory 2325 includes the programming to operate the I/O processor 2325. A 

25 central processor 2324 controls operation of the I/O processor 2325. An ethernet 

26 interface 2330 provides connections to the ethernet 2323 and to the dual rail ethernet 

27 2343. A memory 2333 stores application programs executed by the I/O processor 

28 2321. Finally, SS-7 interface modules 2334 and 2335 provide connections to systems 

29 external to the aircore platform 200. 
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1 Figure 84 shows the logical construction of the TIP 2341 The other TIPs are 

2 the same as the TIP 2341 P A central processor 2344 controls operation of the TIP 

3 2341 A memory 2345 includes the operating programs for the TIP 2341,. A 

4 memory 2348 includes the application programs under control of the TIP 2341 j. The 

5 application programs are described with reference to Figure 10. An interface 2347 

6 connects the TIP 2341 , to the dual rail ethernet 2343. A memory module 2346 

7 includes a hard drive 2349 and a floppy disk interface 2350. An external interface 

8 module 2349 connects the TIP 2341 j to systems external to the aircore platform 200. 

9 Figure 85 shows another hardware embodiment of the aircore platform 2400. 

10 In this embodiment, the aircore platform 2400 includes a 19-inch rack-mountable 

1 1 chassis 24 10. The aircore platform 2400 includes dual loadsharing power supplies 

12 2420 and optional power supplies 2422. The chassis also includes dual mirrored SCSI 

13 disk drives 2430 and optional drive bays 2432. An I/O processor board 2440 connects 

14 to telephony boards slots 1-14 for telephony boards 2470-2485. Finally, the aircore 

15 platform 2400 includes a removable fan tray 2490. 

16 Figure 86 shows the I/O processor in more detail. The I/O processor board 

17 2440 includes a processor 2441 that provides bus control for the telephony boards 

18 2470-2485. The processor 2441 can be an advanced processor such as an Intel 

19 Pentium™ family processor or other processor. The I/O board 2440 also includes a 

20 scalable random access memory 2442. The I/O processor board 2440 provides on- 

21 board PCI video 2443, IDE 2444 and SCSI drive controllers 2445, and multiple serial 

22 I/O ports 2446. Also included are Ethernet connections 2447, floppy disk drives 

23 2448, and PCMCIA slots 2449. The I/O processor board 2440 provides front and rear 

24 access to the I/O devices. The SCSI drives 2445 may be dual mirrored 1.5 Gb hard 

25 drives. The SCSI drives 2445 may be configured in a RAID-1 format. The SCSI 

26 drives 2445 are hot swapable and can be resynchronized in case of failure. 

27 The aircore platform 2400 may provide for local network connectivity and 

28 dial-out access using a standard lObase-T or lOObase-T Ethernet connection for LAN 

29 connecting options and a 56k dial-up modem for remote access dial-in capability. 
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1 Other advanced telecommunications connection devices may also be used with the 

2 aircore platform 2400. Standard telephony boards may be used with the aircore 

3 platform 2400 for T-l/E-1 and ATM communications. For example, the telephony 

4 boards 2470-2485 include TH-B 1240 OCTAL T-l/E-1 interface boards for common 

5 channel signaling based T-ls. TH-BD96 quad T-l interfaces are provided for channel 

6 associated signaling using T-ls. TH-BD120 quad E-l interface devises are used for 

7 channel associated signaling using E-ls. TH-BV30 voice I/O provides 30 ports of I/O 

8 and signal processing. TH-BC64 provides conferencing capabilities. A TH-BSS7 

9 board provides both DS0 and V.35 connections. Each of the telephony boards 2470- 

10 2485 provides 4-6 trunk links. Also connected to the aircore platform 2400 are 

1 1 operator interface devices including a monitor 2491, a keyboard 2492, and a mouse 

12 2493. 

13 The switching architecture of the aircore platform 2300 or 2400 may be the 

14 H.110/H. 100 based standard, forexample. The H. 110 and the H. 100 switching matrix 

15 is a standard Application Specific Integrated Circuit (ASIC) that resides on each board 

16 in the system. This means that rather than shipping all interface channels to a single 

17 point in the system to make and break the connections for switching, each board 

18 controls its own switching. The H. 1 10 switching matrix uses a J4 connector or 

19 connects to the other components of the aircore platform 2400 using a 34 connector on 

20 a back plane of the chassis 2410. There may be a total of 32 streams running at 

21 speeds of 8MH,, Each stream provides 128 channels of 64 kbps. Total bus capacity 

22 ranges from 5 12 to 4096 channels. 

23 The H.100 switching matrix uses a ribbon cable to connect to boards together 

24 to provide the actual streams of digitized channels. There are a total of 32 streams 

25 running at speeds of 2MHz to 8MHz. Each stream provides from 32 to 129 channels 

26 of 64 kbps. The total bus capacity ranges from 5 12 to 4096 channels. 

27 Other switching matrices may also be used with the aircore platform 2400. 

28 The capacity of the aircore platform 2400 may be extended. Multi-chassis 

29 configurations can be provided to claim the switch matrices together. This may be 
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1 accomplished using several standard multi-chassis interconnection interfaces or by 

2 connecting the chassis via E-l or T-l connections. The addition of ATM allows for a 

3 standard extension mechanism to the switch matrix between chassis. 

4 Other hardware configurations besides the two embodiments described above 

5 are available with the aircore platform 200. 

6 The aircore platform 200 incorporates graphical user interfaces (GUIs) to aid 

7 operator manipulation of system data. Figures 87-1 19 show the hierarchy of windows 

8 used with the GUIs and also show examples of GUI screens used with the aircore 

9 platform 200. 

10 Figure 87 shows the hierarchy of windows used with the aircore HLR 424. A 

1 1 hierarchy 3000 includes a home location register icon screen 3001 which is initially 

12 displayed. Upon entry of a password in a password screen 3002, a home location 

13 register access screen 3003 is displayed. Using the home location register access 

14 screen 3003, an operator can choose one of the screens 3004-3009 for GSM, CDMA, 

15 TDMA, AMPS, multi-mode protocols, or for prepaid services. Finally, corresponding 

16 to each of the wireless protocols is a separate prepaid screen 3010-3014. 

17 GSM subscriber profiles are configured as per the GSM feature set. CDMA 

18 subscriber profiles are configured as per the CDMA (IS-664) feature set. Multi-mode 

19 subscriber profiles may be configured for multiple air interfaces. Multi-mode 

20 subscribers use the common feature set between the GSM, CDMA, TDMA and 

21 AMPS protocols. All of the above subscriber profiles can incorporate prepaid feature 

22 functionality. 

23 Prepaid subscriber profiles are configured as strictly prepaid in the aircore 

24 system. Prepaid subscribers may use wireless or wireless prepaid features. 

25 Figure 88 shows the GSM subscriber window 3004 in more detail. A number 

26 of subscribers block 3021 lists the current number of subscribers in the HLR 424 as 

27 well as the capacity of the HLR 424. The subscriber list 3022 individually lists the 

28 subscribers to the aircore systems. A previous button 3025 and a next button 3026 

29 loads the previous or next group of subscribers into the subscriber list scroll box 3022. 
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A properties button 3023 allows modification of data for the selected subscriber. A 
search button 3024 allows for search of the HLR 424 when a subscriber MSISDN 
number is input at the search line. An add button 3027 and a delete button 3028 allow 
the addition or deletion of a subscriber profiled in the HLR 424. A report button 3029 
allows an operator to view a change report file created for HLR 424 modifications. 

Figure 89 is an example of an individual subscriber profile for a GSM 
subscriber. The subscriber profile 3030 includes a customer and mobile unit 
identification block 3031, call offering block 3032, call restriction block 3033, and 
call restrictions block 3034. Also included is a call features block 3035, and line 
identification block 3036. 

Subscriber profiles for other wireless protocols are similar to that described 
above for a GSM subscriber. 

Figure 90 shows a routing administration windows hierarchy 31 10 associated 
with establishing routing translations in the aircore systems. The initial screen is a 
database management icon screen 3101. Next, a routing administration tab 3102 is 
display. Linked to the routing administration tab 3102 is a customer group properties 
screen 3103. Also linked to the routing administration tab 3102 is a standard routing 
screen 3104, a feature codes screen 3105, an emergency call routing screens 3106 and 
a tones and announcement screen 3107. The data displayed in the screens 3104-3107 
may be modified by displaying an add/modified/delete screen 3108. 

Figure 91 shows the routing administration tab 3 102. A customer group scroll 
box 3111 shows the customer groups that are currently active in the aircore system. 
The customer group is a required piece of data that is assigned to both customers and 
trunk groups. The number assigned is used as an index into the appropriate routing 
table for processing an incoming call. The routing translations determine the 
allowable calls, the type of call, and the appropriate system routing for the call. Each 
customer group can accommodate hundreds of individual from-to routing translation 
entries. The translations can provide support for any dialing plan between 1 and 32 
digits. Dialing plans of varying lengths maybe configured within the same customer 
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1 group. Each line of translations within each customer group provides a primary and 

2 alternate route based on the trunk group. In addition, each route is provided its own 

3 digit manipulation parameters (strip and prefix digits). The aircore system can 

4 accommodate up to 100 customer groups. 

5 Figure 92 shows a customer group modification window 3120. The customer 

6 group modification window 3 120 defines the overall properties associated with a 

7 particular customer group. Check boxes 3121 allow for the configuration of three 

8 alternate types of translations. 

9 Figure 93 shows the standard routing translation window 3 104. A scroll box 

10 3131 is used to display portions of the information. The information displayed in the 

11 scroll box 3131 includes "from" data, which is the number the range starts from; "to" 

12 data, which is the number the range ends at; min, which is the minimum length of the 

13 digit string; max, which is the maximum length of the digit string; and type, which is 

14 the type of call the number range indicates. Also shown is the route number of the 

15 trunk and the numeric trunk group number. 

16 Figure 94 shows the standard routing translations modifications window 3108. 

17 The standard routing translations modifications window 3108 provides the operator 

18 access to modify the selected number range. The window is used for adding or 

19 modifying ranges in the standard routing translations window 3 104. 

20 Figure 95 shows the feature code routing translation window 3105. The 

21 feature code routing translation window 3105 includes a scroll box 3151 that displays 

22 a portion of the information selected by the operator. The feature code routing 

23 translation window 3105 contains the information related to routing feature 

24 manipulation calls for the aircore system. The parameters supplied in the feature code 

25 routing translation window 3 105 are used to determined the type of feature 

26 manipulation and the appropriate system action. 

27 Figure 96 shows the emergency call routing translations window 3106. A 

28 scroll box 3161 displays currently selected information. The information includes 

29 "from" data which is the number the digit range starts from. The "from" data can be 
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